Ribbon filter

RocksDB 的 blog 上看到「Ribbon Filter」這個,主要是 RocksDB 從 6.15 開始支援 Ribbon filter,取代本來的 Bloom filter 機制。

RocksDB 的 wiki 上面是說用 CPU 資源換 memory 的使用量:

A new Bloom filter alternative is available as a drop-in replacement (since version 6.15.0), saving about 30% of Bloom filter space (most importantly, memory) but using about 3-4x as much CPU on filters. Most of the additional CPU time is in the background jobs constructing the filters, and this is usually a good trade because it is common for SST filters to use ~10% of system RAM and well under 1% of CPU.

論文則是在「Ribbon filter: practically smaller than Bloom and Xor」這邊可以看到,Facebook 之前也有提到 Ribbon filter:「Ribbon filter: Practically smaller than Bloom and Xor」,在 Hacker News 上有對應的討論可以翻:「Ribbon filter: Practically smaller than Bloom and Xor (fb.com)」。

在 Ribbon filter 的資料裡面都提到了 Xor filter 當作比較,先前在「比 Bloom filter 與 Cuckoo filter 再更進一步的 Xor filter」這邊有提到 Xor filter。

用 CPU 去換記憶體,算是特化的版本...

在 Minecraft 裡面幹出一台完整的電腦

Lobsters Daily 上看到有強者在 Minecraft 實做邏輯電路,幹出一台完整的電腦出來 (CPU 的部份應該是 turing-complete 了):

PCWorld 有報導:「This 8-bit processor built in Minecraft can run its own games」。

把影片裡的描述截圖出來:

連分支預測器都出現了:

記憶體就 Minecraft 來說也是超大的 256 bytes:

然後還做了 cache 層,這邊提到的是 data cache:

然後這邊是 instruction cache:

也因為已經相當的 powerful,很多經典遊戲都可以玩,像是俄羅斯方塊:

貪食蛇:

打磚塊:

Connect Four

AWS 要推出 Graviton3 的機種了

AWS 打算要推出 Graviton3 的機種了,目前還在 preview 階段:「Join the Preview – Amazon EC2 C7g Instances Powered by New AWS Graviton3 Processors」。

目前是宣稱與前一代的 Graviton2 相比有 25% 的效能提昇,另外在浮點數與密碼相關的運算上面也會有改善 (這個效能提昇的數字應該是有指令集的幫助):

In comparison to the Graviton2, the Graviton3 will deliver up to 25% more compute performance and up to twice as much floating point & cryptographic performance. On the machine learning side, Graviton3 includes support for bfloat16 data and will be able to deliver up to 3x better performance.

另外提到了 signed pointer,可以避免 stack 被搞,不過這邊需要 OS 與 compiler 的支援,算是針對 stack 類的攻擊提出的防禦方案:

Graviton3 processors also include a new pointer authentication feature that is designed to improve security. Before return addresses are pushed on to the stack, they are first signed with a secret key and additional context information, including the current value of the stack pointer. When the signed addresses are popped off the stack, they are validated before being used. An exception is raised if the address is not valid, thereby blocking attacks that work by overwriting the stack contents with the address of harmful code. We are working with operating system and compiler developers to add additional support for this feature, so please get in touch if this is of interest to you.

然後是使用 DDR5 的記憶體:

C7g instances will be available in multiple sizes (including bare metal), and are the first in the cloud industry to be equipped with DDR5 memory. In addition to drawing less power, this memory delivers 50% higher bandwidth than the DDR4 memory used in the current generation of EC2 instances.

現在還沒看到價錢,不過有可能是跟 c6g 一樣的價位?但考慮到記憶體換架構,也有可能是貴一些的?

另外翻了一下資料,ARM 有發表過新聞稿提到 Graviton2 是 ARM 的 Cortex-M55 機種:「Designing Arm Cortex-M55 CPU on Arm Neoverse powered AWS Graviton2 Processors」,這次的 Graviton3 應該在之後完整公開後會有更多消息出來...

來看 Intel + Varnish 的單機 500Gbps 的 PR 新聞稿

在「Varnish Software Achieves 500Gbps Throughput Per Server for UHD Video Content」這邊看到 PR 稿,由 IntelVarnish 合作,宣稱達到單機 500Gbps 的 throughput 了:

According to Varnish Software, the following were the outcomes of the test:

  • 509.7 Gbps live-linear throughput, using a dual-processor configuration
  • 487.2 Gbps video-on-demand throughput, using a dual-processor configuration

白皮書在「Delivering up to 500 Gbps Throughput for Next-Gen CDNs」這頁可以用個資交換下載,不過用搜尋引擎找一下可以發現 Intel 那邊有放出 PDF (但不確定兩邊給的是不是同一份):「Delivering up to 500 Gbps Throughput for Next-Gen CDNs」。

單 CPU 的伺服器是四個 100Gbps 界面接出來,雙 CPU 的伺服器是八個 (這邊 SUT 是 system under test 的縮寫):

These client systems were connected to the CDN servers using 100 GbE links through a switch; 4x100 GbE connections for the single-processor SUT, and 8x100 GbE for the dualprocessor SUT. Testing was done using Wrk, a widely recognized open-source HTTP(S) benchmarking tool.

不過如果實際看圖會發現伺服器是兩個 100Gbps (單 CPU) 與四個 100Gbps (雙 CPU),然後 wrk 也吃了兩個或是四個 100Gbps:

在白皮書最後面也有提到測試的配置,都是在 Ubuntu 20.04 上面跑,單 CPU 用的是兩張 Intel 的 100Gbps 網卡,雙 CPU 的用的是四張 Mellanox 的 100Gbps 網卡:

3rd generation Intel Xeon Scalable testing done by Intel in September 2021. Single processor SUT configuration was based on the Supermicro SMC 110P-WTR-TNR single socket server based on Intel® Xeon® Platinum 8380 processor (microcode: 0xd000280) with 40 cores operating at 2.3 GHz. The server featured 256 GB of RAM. Intel® Hyper-Threading Technology was enabled, as was Intel® Turbo Boost Technology 2.0. Platform controller hub was the Intel C620. NUMA balancing was enabled. BIOS version was 1.1. Network connectivity was provided by two 100 GbE Intel® Ethernet Network Adapters E810. 1.2 TB of boot storage was available via an Intel SSD. Application storage totaled 3.84TB per drive and was provided by 8 Intel P5510 SSDs. The operating system was Ubuntu Linux release 20.04 LTS with kernel 5.4.0-80 generic. Compiler GCC was version 9.3.0. The workload was wrk/master (April 17, 2019), and the version of Varnish was varnishplus-6.0.8r3. Openssl v1.1.1h was also used. All traffic from clients to SUT was encrypted via TLS.

3rd generation Intel Xeon Scalable testing done by Intel in September 2021. Dual processor SUT configuration was based on the Supermicro SMC 22OU-TNR dual socket server based on Intel® Xeon® Platinum 8380 processor (microcode: 0xd000280) with 40 cores operating at 2.3 GHz. The server featured 256 GB of RAM. Intel® Hyper-Threading Technology was enabled, as was Intel® Turbo Boost Technology 2.0. Platform controller hub was the Intel C620. NUMA balancing was enabled. BIOS version was 1.1. Network connectivity was provided by four 100 GbE Mellanox MCX516A-CDAT adapters. 1.2 TB of boot storage was available via an Intel SSD. Application storage totaled 3.84TB per drive and was provided by 12 Intel P5510 SSDs. The operating system was Ubuntu Linux release 20.04 LTS with kernel 5.4.0-80- generic. Compiler GCC was version 9.3.0. The workload was wrk/master (April 17, 2019), and the version of Varnish was varnish-plus6.0.8r3. Openssl v1.1.1h was also used. All traffic from clients to SUT was encrypted via TLS.

不過馬上就會滿頭問號,四張 100Gbps 是怎麼跑到 500Gbps 的頻寬...

這份 PR 馬上就讓人想到 Netflix 先前放出來的投影片 (先前有在「Netflix 在單機服務 400Gbps 的影音流量」這篇提到),在 Netflix 的投影片裡面有提到他們在 Intel 平台上面受限於記憶體的頻寬,整台機器只能跑到 230Gbps。

另外一種猜測是,如果 Intel 與 Varnish 宣稱的 500Gbps 是算 switch 上的總流量 (有這樣算的嗎,你是 Juniper 嗎...),那這邊的 500Gbps 換算回去差不多就是減半 (還很客氣的沒把 cache 沒中需要去 origin server 拉資料的流量扣掉),跟 Netflix 在 FreeBSD 上跑出來的結果差不多啊...

坐等反駁 XDDD

Amazon RDS 支援 ARM 架構的 t4g 與 x2g

這兩篇剛好一起看,Amazon RDS 支援了 ARM 架構的 t4gx2g:「Amazon RDS now supports X2g instances for MySQL, MariaDB, and PostgreSQL databases.」與「Amazon RDS now supports T4g instances for MySQL, MariaDB, and PostgreSQL databases.」。

目前主要是關注 t4g,因為目前量的關係反而是大量使用 t4g 類的機器,如果上面的 PostgreSQL 可以跑 t4g 的話,看起來只要沒有買 RI 的可以換過去,主要是比 t3 再省一些錢:以新加坡區的 PostgreSQL 來說,db.t4g.micro 目前是 $0.025/hr,而 db.t3.micro 則是 $0.028/hr,差不多是九折。

沒意外的話效能應該也會提昇一些,不過用 t 系列的機器本來就沒有太大的量在上面跑,這點應該是還好...

Intel 與 AMD 在 RSQRTSS 的不同

看到「rr Trace Portability: Diverging Behavior of RSQRTSS in AMD vs Intel」這個,作者因為在 rr 上發現 replay 不正確,發現是 SSE 裡面的 RSQRTSS 這個指令在 IntelAMD 平台上會有不同的值出現導致的。

RSQRTSS 是計算平方根倒數,也就是計算 1 / \sqrt{x},另外比較特別的是,這個指令不保證正確性,是允許有誤差產生的。

提到平方根倒數,這個演算法更有名的應該是「反平方根快速演算法」這個用到 0x5f3759df 這個魔術數字的奇技淫巧,不過這不是這次的重點...

作者發現 RSQRTSS 在 Intel 與 AMD 平台的值不一定一樣,像是 256 的平方根導數是 1/16 (0.0625),但兩個平台跑出來不同:

On Intel Skylake I get
out = 3d7ff000, float = 0.062485

On AMD Rome I get
out = 3d7ff800, float = 0.062492

在這邊的 case 可以看出來 AMD 算的比較正確 (誤差值比較低),但都還是在 spec 允許的誤差範圍。

後來作者還發現有其他不同的指令也有類似的問題,為了解決在 rr 上可以正確 replay 的問題,他生了對應的 mapping table 來解:「Emulating AMD Approximate Arithmetic Instructions On Intel」。

苦啊... 不過這個主題還蠻有趣的。

Amazon EC2 上的一些小常識

Twitter 上看到 Laravel News 轉發了「Mistakes I've Made in AWS」這篇,講 Amazon EC2 上面的一些小常識。

在 EC2 中,T 系列的機器 (目前主要是 t2/t3/t3a/t4g) 對於開發很好用,甚至對於量還不大的 production system 也很好用,加上 Unlimited 模式可以讓你在 CPU credit 用完時付錢繼續 burst。

文章裡面有討論到,使用 T 系列機器時,常常是不怎麼需要大量 CPU 資源的情境,這時候 AMD-based 的 t3a 通常都是個還不錯的選擇,大概會比 Intel-based 的 t3 省 10% 的費用。另外如果可以接受 ARM-based 的話,t4g 也是個選項,價錢會更便宜而且在很多應用下速度會更快。不過同事有遇到 Python 上面跑起來的行為跟 x86-64-based 的不同,這點就得自己琢磨了...

另外就是目前的 EBS 預設還是會使用 gp2,而在 gp3 出來後其實大多數的情況下應該可以換過去,主要就是便宜了 20%,加上固定的 3000 IOPS。

不過也是有些情境下是不應該換的,主要是 gp2 可以 burst 到 250MB/sec,但 gp3 只給了 125MB/sec。雖然 gp3 可以加價買 throughput,但加價的費用不低,這種需求改用 gp2 應該會比較划算。

不過這邊推薦比較技術的作法,可以掛兩個 gp3 (也可以更多) 跑 RAID0 (像是在 Linux 上可以透過 mdadm 操作),這樣 IOPS 與 throughput 都應該可以拉上來...

Amazon EC2 推出 m6i 的機器

AWS 給了公告,在 Amazon EC2 上面推出了 m6iIntel-based 新機種:「New – Amazon EC2 M6i Instances Powered by the Latest-Generation Intel Xeon Scalable Processors」。

這好像是第一次看到 Intel-based 機種加上了 i 的 suffix...

這次比較大的兩個差異,與 m5 相比,多出了 m6i.32xlarge

A larger instance size (m6i.32xlarge) with 128 vCPUs and 512 GiB of memory that makes it easier and more cost-efficient to consolidate workloads and scale up applications.

另外看了一下 us-east-1 上的單價,看起來與 m5 系列的機器價錢一樣,但是效能提昇了 15% (然後很假掰的寫了 price/performance?):

Up to 15% improvement in compute price/performance.

單以數字看起來的話還是 m6g 系列會比較香?當然如果只有 x86-64 binary 的話看起來還是可以考慮換到 m6i 上跑...

在 AWS 上面的 OpenVPN Server 效能

這篇的後續可以參考「Amazon EC2 的網路效能」這篇。

最近在在調整跑在 Amazon EC2OpenVPN server 的效能,要想辦法把 network throughput 拉高,當作在導入 WireGuard 之前的 workaround,但看起來還是頗有用,記錄一下可以調整的部份...

在還沒灌大量流量前是用 t3a.nano (開 Unlimited mode),然後會觀察到的瓶頸是 OpenVPN 的 daemon 吃了 100% CPU loading,最高速度卡在 42MB/sec 左右。

第一個想到的是看看 OpenVPN server 有沒有可以使用多 CPU 的方式,但查了資料發現 OpenVPN server 無法使用 threading 或是 fork 之類的方法善用多顆 CPU,所以就開始想其他方法...

接著看到我們目前用的是 AES-256-CBC 了,網路上很多文章都有提到 AES-128-CBC 會快一些,但我們的 OpenVPN client 已經是設死都用 AES-256-CBC 了,這個就沒辦法了...

而第一個可行的解法是把 AMD-based 的 t3a.nano 換成 ARM-based 的 t4g.nano,還是 100% 的 CPU loading,但直接多了 50%+ 的效能,到了 69MB/sec。

第二個解法是找資料時發現的 fast-io 參數,加上去以後可以再快一些,到 77MB/sec。

有了這兩個 workaround 應該就堪用了,接下來是發現在傳大量資料跑一陣子後速度會掉下來,於是開了兩台 t4g.nanoiperf 對測了一下,發現會逐步掉速:

  • 前 15 秒可以直接到 5Gbps,就是 AWS 網頁上宣稱的最高速度,接下來降到 800Mbps 左右。
  • 到 180 秒左右後降到 300Mbps。
  • 到 210 秒左右後回到 800Mbps。
  • 到 300 秒左右後降到 500Mbps。
  • 到 300 秒左右後降到 300Mbps。
  • 到 1260 秒左右後降到 30Mbps,後面就一直維持這個速度了。

看起來 network bandwidth credit 是分階段的,但 30Mbps 真的有點低...

在換成四倍大的 t4g.small 測試後發現也只能到 40MB/sec 左右 (比較疑惑的是,居然不是四倍?),目前上了 c6g.medium,但看起來網路的部份也還是有瓶頸,在 46MB/sec 左右,要再想一下下一步要怎麼調整...

但以目前看到的情況總結,如果能用 ARM 架構就儘量用,效率與價錢真的是好 x86-64 不少...

Cloudflare 開始在正式環境用 ARM server 了

在「Designing Edge Servers with Arm CPUs to Deliver 57% More Performance Per Watt」這邊 Cloudflare 提到了他們在正式環境用 ARM 架構了:

Our first Arm CPU was deployed in production earlier this month — July 2021.

記得測了很多年,其中遇到測試到一半看起來還不錯,但原廠商決定不繼續做的,直到後來又有廠商投入,到現在總算是有比較成熟的產品可以用。

隔壁棚 AWS 上的 ARM 伺服器用起來也是香到不行,還沒有用過的可以試看看,至少我這台 blog & wiki 也都是跑在上面。

另外文章裡有提到目前 x86 的效能,新一代的 AMD 大概只比前一代多了 39% 的每瓦效能,但如果是把 ARM 拿進來比的話會到 57%:

Our most recently deployed generation of edge servers, Gen X, used AMD Rome CPUs. Compared with that, the newest Arm based CPUs process an incredible 57% more Internet requests per watt. While AMD has a sequel, Milan (and which Cloudflare will also be deploying), it doesn’t achieve the same degree of energy efficiency that the Arm processor does — managing only 39% more requests per watt than Rome CPUs in our existing fleet.

開始推上 production 後應該會愈換愈快,而且代表 Cloudflare 也會開始針對 ARM 平台最佳化。