Hardware

Netflix 在單機服務 400Gbps 的影音流量

在 Hacker News 首頁上看到 Netflix 在 EuroBSDCon 2021 上發表的投影片：「Serving Netflix Video at 400Gb/s on FreeBSD」，對應的討論則是在「Serving Netflix Video at 400Gb/s [pdf] (freebsd.org)」這邊可以翻到，投影片的作者有在上面回答一些問題。

投影片在講的應該就是 Netflix 的 Open Connect。

主要是因為 Open Connect 的伺服器是放到各家 ISP 機房，在單一 IP 且單一伺服器的限制下，要想辦法壓榨出最高的效能。

硬體是 AMD 的 EPYC，在先前的版本可以達到 240Gbps，經過分析與嘗試解決了一堆問題後，最後是在原來的 AMD 機器上跑到了 380Gbps (另外有測 ARM 以及 Intel 的數字)，然後之後機房有可能會有 800Gbps 的標準，他們又要繼續煩惱...

有看到 Mellanox ConnectX-6 Dx (CX6-DX) 這個東西，看起來很有趣啊，有 200Gbps 的能力，而且可以把 TLS 的事情推到卡上面處理... 然後這家公司被 Nvidia 買走了。

另外當然也會有人問為什麼不用 Linux，作者在討論串裡面也有回答一些，有興趣的可以自己去搜一下。

Amazon EC2 推出 VT1 Instance

看到 Amazon EC2 推出新機種 vt1，專門為影片壓縮而推出的 family type：「New – Amazon EC2 VT1 Instances for Live Multi-stream Video Transcoding」。

主要是透過 Alveo U30 Data Center Accelerator Card 這張卡加速，號稱比 GPU 機器還要省 30% 的費用 (CPU 的話可以到 60%)：

These VT1 instances feature Xilinx® Alveo™ U30 media accelerator transcoding cards with accelerated H.264/AVC and H.265/HEVC codecs and provide up to 30% better price per stream compared to the latest GPU-based EC2 instances and up to 60% better price per stream compared to the latest CPU-based EC2 instances.

看規格支援 H.264 與 H.265，不過看起來沒支援 royalty-free 的 VP9 與 AV1...

另外這跟 AWS Elemental MediaConvert 以及 AWS Elemental Live 好像稍微有點打對台？另外專利的費用不知道怎麼算...

用 Ephemeral Storage 加速 MySQL over ZFS 的效能

在 Percona 的「MySQL/ZFS in the Cloud, Leveraging Ephemeral Storage」這篇裡面在探討是不是可以看看 ZFS 在 Ephemeral Storage (機器附的本地硬碟) 上的效能。

一開始測試是直接當主力硬碟來測，可以看到跑 ZFS 的情況下，本地的 storage 還是會比 SSD Premium (這是 Azure 的產品線) 還快不少：

但把資料放在本地的 storage 上其實有點刺激，至少在 production 應該不太會這樣搞，所以後面用 L2ARC 的方式來測，可以看到效率提昇相當明顯，甚至接近本來直接把資料放在本地的 storage：

另外測了 ext4/bcache，看起來效率就沒那麼好：

這樣看起來是個不錯的選擇...

Intel 與 AMD 在 RSQRTSS 的不同

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

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 上面推出了 m6i 的 Intel-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 上跑...

很多 ls 開頭的指令...

在 Twitter 上看到 ls* 指令：

ls* Commands Are Even More Useful Than You May Have Thought: https://t.co/G6ragdRv60

— hackerbot (@hackerb0t) August 11, 2021

文章是「ls* Commands Are Even More Useful Than You May Have Thought」這篇，本來以為是要裝軟體的，結果發現在講的都是已經內建裝好的指令...

包括了很多跟底層硬體界面相關的指令：

lsblk (儲存裝置相關)
lshw (硬體)
lscpu (CPU)
lspci (PCI)
lsusb (USB)

可以用一次有個感覺就好，這個年頭遇到問題時還是會靠搜尋引擎找答案 XDDD

Amazon EC2 的網路效能

前一篇「在 AWS 上面的 OpenVPN Server 效能」最後的問題就是 EC2 instance 本身的網路效能，畢竟是公司要用的，還是實際測一下數字，之後有人接手的時候也比較清楚是怎麼選這個大小的...

這邊拿的是 AWS 的 ap-southeast-1 (Singapore) 的 EC2 測試，直接在同一個 subnet 裡面開兩台一樣的機器跑 iperf 測試。

機器開機後會先跑這串指令 (除了安裝 iperf 的指令，其他的是出自我自己 wiki 上的 Ubuntu 這頁)，然後再重開機：

sudo fallocate -l 512M /swapfile; sudo chmod 600 /swapfile; sudo mkswap /swapfile; sudo swapon /swapfile; echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab; echo -e "net.core.default_qdisc=fq\nnet.ipv4.tcp_congestion_control=bbr" | sudo tee /etc/sysctl.d/99-tcp.conf; sudo sysctl -p /etc/sysctl.d/99-tcp.conf; sudo apt update; sudo apt dist-upgrade -y; sudo apt install -y apache2-utils apt-transport-https build-essential curl dnsutils dstat git jq locales moreutils most mtr-tiny net-tools p7zip-full pigz prometheus-node-exporter rsync sharutils software-properties-common sysstat unrar unzip vim-nox wget zsh zsh-syntax-highlighting zstd; sudo apt install -y iperf; sudo apt clean

接下來就是一台跑 iperf -s，另外一台跑 iperf -c 10.x.x.x -i 1 -t 3600 讓他跑一個小時看結果了。

我都有跑 tmux 再連到這些機器上，這樣可以捲回去看每一秒的傳輸速度，就可以看出來變化了，不過這邊還是簡單的只列出最高速度 (burstable) 與穩定輸出的速度 (baseline)：

EC2 instance	Baseline	Burstable	vCPU	RAM	Pricing (USD$)
c6g.medium	500Mbps	10Gbps	1	2GB	0.0392
c6g.large	750Mbps	5Gbps (claimed 10Gbps)	2	4GB	0.0784
c6g.xlarge	1.25Gbps	10Gbps	4	8GB	0.1568
t4g.small	125Mbps	5Gbps	2	2GB	0.0212
t4g.medium	255Mbps	5Gbps	2	4GB	0.0424
t4g.large	510Mbps	5Gbps	2	8GB	0.0848
t4g.xlarge	1Gbps	5Gbps	4	16GB	0.1696

這邊沒列出來的是 burstable 可以持續的時間，但這跟你機器吃的網路資源有關，我就決定只用 baseline 來做決策了，這樣可能會多花一點錢，但會少很多麻煩。

另外這次在處理的過程有被同事提醒各種 bandwidth overhead，所以就順便查了一下資料：

OpenVPN 本身的 overhead 大約是 5% (跑 UDP 的時候)：「OpenVPN performance」。
SSH 也有些 overhead，大約是 6% (把來回的封包都算進去)：「What is the overhead of SSH compared to telnet?」。
rsync 的部份鐵定也有 overhead，但這邊就沒找到現成的文章有統計過了。
另外我自己之前做實驗發現 TCP BBR 的 retransmission algorithm 還蠻激進的，會有 10% packet loss，改用預設的 CUBIC 會好很多，大約 1% 到 2% 左右。

綜合這些測試，我自己抓了 35% 的 overhead 來推估，最後是用 c6g.large 來養 VPN server。750Mbps 的實際流量大約可以包進 550Mbps 的原始流量，大約是 68MB/sec。

不過新加坡與印尼之間的 internet bandwidth 好像還是不太夠，有時候深夜跑也跑不滿... 不過之後 VPN 上的 client 會愈來愈多，應該是不需要降...

在 AWS 上面的 OpenVPN Server 效能

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

最近在在調整跑在 Amazon EC2 上 OpenVPN 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.nano 用 iperf 對測了一下，發現會逐步掉速：

前 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 平台最佳化。