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

Hacker News 首頁上看到 NetflixEuroBSDCon 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 且單一伺服器的限制下,要想辦法壓榨出最高的效能。

硬體是 AMDEPYC,在先前的版本可以達到 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.264H.265,不過看起來沒支援 royalty-free 的 VP9AV1...

另外這跟 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 這個指令在 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 上跑...

很多 ls 開頭的指令...

Twitter 上看到 ls* 指令:

文章是「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 本身的網路效能,畢竟是公司要用的,還是實際測一下數字,之後有人接手的時候也比較清楚是怎麼選這個大小的...

這邊拿的是 AWSap-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 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 平台最佳化。