Netflix 單機 800Gbps 伺服器所使用的最佳化技巧

Hacker News 上看到 Netflix 的人丟出來的投影片,試著了解 Netflix 的 Open Connect Appliances 裡與 FreeBSD 相關的最佳化技巧對於效能的影響:「The “other” FreeBSD optimizations used by Netflix to serve video at 800Gb/s from a single server」。

看起來這邊的分析是先基於 400Gbps 的版本,可以跑到 375Gbps (53% CPU),接著在上面拔掉各種最佳化的設定,看看會掉多少流量。這邊可以參考先前在「Netflix 在單機服務 400Gbps 的影音流量」提到的資料。

投影片上的第一章是 sendfile 與 kTLS 相關的最佳化,這邊可以看出來都是重要的項目,隨便關掉一個就會掉很多 capacity:

  • Disable kTLS (and async sendfile) + nginx aio:40Gbps (100% CPU)
  • Disable kTLS (and async sendfile) + nginx thread pools:90Gbps (90% CPU)
  • Disable sendfile (but use kTLS):75Gbps (80% CPU)
  • Disable sendfile (but use NIC kTLS):95Gbps (80% CPU)
  • Enable Sendfile & kTLS, but disable ISA-L crypto:180Gbps (80% CPU)
  • Enable Sendfile & kTLS:240Gbps (80% CPU)

第二章是 virtual memory,UMA VM Page Cache 這邊看起來最明顯,SF_NOCACHE 也是個重要的項目:

  • Disable UMA VM Page Cache:60Gbps (95% CPU)
  • Disable VM Batch Queues:280Gbps (95% CPU)
  • Disable SF_NOCACHE:120Gbps (55% CPU)

另外第二章特別提到了一個之前沒有用到的 optimization,是把 arm64 上面的 4KB Pages 變成 16KB Pages,這帶動了些許的效能提昇,並且降低了 CPU 使用率:

345Gb/s @ 80% CPU -> 368Gb/s @ 66% CPU

第三章是 network stack,看起來 TSO 帶來的效益也是很高:

  • Disable TCP Large Receive Offload:330Gbps (65% CPU)
  • Disable RSS accelerated LRO:365Gbps (70% CPU)
  • TSO Disabled:180Gbps (85% CPU)
  • Disable TSO and LRO:170Gbps (85% CPU)

最後面則是有提到從 400Gbps 到 800Gbps 還多做了那些事情,最後是達到 731Gbps。

用的機器是 Dell PowerEdge R7525,這是一台 2U 的機器啊...

FreeBSD 的 Firecracker 支援

Colin PercivalFreeBSD 能夠支援 Firecrack:「Announcing the FreeBSD/Firecracker platform」,成為 LinuxOSv 以外的第三個支援的作業系統。對應的 patch 在「amd64: Add FIRECRACKER kernel configuration」這邊可以看到。

接下來是反過來,要送一些 patch 進去 Firecracker,讓他支援 FreeBSD:

Now that FreeBSD supported Firecracker, there was one more thing to do: Make Firecracker support FreeBSD.

看起來是基於之前在 2020 年的 patch (但當時沒被整進去) 再修改:

Alejandro Jimenez contributed patches two years ago, but they were never merged. Some of his code ended up in the linux-loader project (which Firecracker uses); but I spent a few weeks digging through his thousand lines of changes to figure out which went into linux-loader, which still applied cleanly to Firecracker, and which I had to rewrite from scratch — a task made more difficult by the fact that Firecracker is written in Rust, and I had never used Rust before! Nevertheless, I was eventually successful, and opened a PR with updated patches which I hope to see merged into mainline Firecracker in the upcoming weeks.

看起來兩邊都有 patch 要做才能支援,目前看起來 Firecracker 這邊沒動作了,大概是沒什麼動力...

FreeBSD 的 Amazon EC2 Image 打算自動使用本機空間當作 Swap

Twitter 上看到 Colin Percival 說計畫將 FreeBSD EC2 image (AMI) 自動偵測並使用 ephemeral disk 的空間當作 swap:

就算是使用 EBSgp2 或是 gp3,甚至是其他 VPS,我也很習慣開一點點的 swap 空間來用 (通常是用 file swap 的方式開 512MB,無論記憶體有多大),這算是我自己的 best practice 了,這可以把一些完全沒用到的 daemon 塞進 swap。

不過對於已經把 ephemeral disk 規劃拿來用的人可能會不太開心,需要去改設定...

FreeBSD 把 root 預設的 shell 改成 /bin/sh

Hacker News 首頁上看到 FreeBSD 把 root 的 shell 從 /bin/csh 換成 /bin/sh 了:「sh(1): make it the default shell for the root user」,Hacker News 上的討論也可以看一看:「FreeBSD switches the default root shell from csh to sh (freebsd.org)」。

依照說明是把 FreeBSD 的 /bin/sh 加上了不少東西,所以算是堪用了:

In the recent history sh(1) has gain the missing features for it to
become a usable interractive shell:
- command completion
- persistent history support
- improvements on the default bindings in emacs mode
- improvements in the vi mode (repect $EDITOR)
- print a newline when exiting via ^D
- default prompt and improvements on how PS1 can be configured
- and more.

This changes also simplifies making tiny freebsd images with only sh(1)
as a shell

以前也是用 csh 系列的 (像是 tcsh),後來開始用 Linux 就往 BashZsh 定居了...

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,作者在討論串裡面也有回答一些,有興趣的可以自己去搜一下。

FreeBSD & pfSense 上的 WireGuard 問題

FreeBSDpfSense 上的 WireGuard 實做問題前幾天被 Ars 的人整理出來:「Buffer overruns, license violations, and bad code: FreeBSD 13’s close call」,文章有點長度,但整個劇情有種在看八點檔的感覺... 在 Hacker News 上的「Buffer overruns, license violations, and bad code: FreeBSD 13’s close call (arstechnica.com)」與後續的「In-kernel WireGuard is on its way to FreeBSD and the pfSense router (arstechnica.com)」都值得翻翻。

目前 FreeBSD 與 pfSense 都已經把現有的 WireGuard 實做拿掉,主要原因是實做本身的品質很差 (以及安全性問題),而且沒有將 WireGuard 的功能實做完整。

文章裡面有提到兩個組織面上的問題 (還有攻擊個人的部份,這邊就不提了),第一個是 FreeBSD 的 review process,看起來比較像是系統面的問題,目前還是缺乏人力。

另外一個是 Netgate 本身 (pfSense 後面的公司),本來沒有太多背景知識,但這次事件發生後跑去翻了一下資料,發現原來之前就有一些「記錄」了,像是註冊競爭對手的產品 OPNsense 沒有註冊的網域 opnsense.com,然後導去 pfSense 家的事情,最後使得 Deciso (OPNsense 後面的公司) 到 WIPO 上搶回來:「WIPO Domain Name Decision: D2017-1828」。

可以花些時間來看看替代方案...

sscanf() 與 strlen() 的故事繼續發展

昨天在「GTA 的啟動讀取效能問題」這邊提到了 sscanf()strlen() 的問題,剛剛在 Hacker News Daily 上又看到一篇「It Can Happen to You」,在講他自己的專案也中獎。

他提到了一個解法,用 strtof() 取代 sscanf() 讀數字,結果大幅降低了 parsing 的時間:

Replacing the sscanf call with strtof improved startup by nearly a factor of 10: from 1.8 seconds to 199 milliseconds.

文章的最後面題到了不少目前正在進行中的討論與 patch。

首先是 FreeBSD 上的 patch 已經在測試:「address a performance problem w/ partial sscanf on long strings...」,裡面可以看到有很小心的在研究會不會造成 performance regression。

然後是 glibc 這邊,在 2014 年就有被開了一張票提出來:「Bug 17577 - sscanf extremely slow on large strings」,不過下面只是多了幾個 comment,目前沒有任何進度。

然後是 cppreference.com 上的「std::scanf, std::fscanf, std::sscanf」頁面則是加注了複雜度的問題:

Complexity

Not guaranteed. Notably, some implementations of sscanf are O(N), where N = std::strlen(buffer) [1]. For performant string parsing, see std::from_chars.

感覺接下來應該還會有更多人提出自己的災情,或是有人發現某個跑很慢的專案也是因為這個原因...

FreeBSD 要從 Subversion 換到 Git

#bsdchat 上面看到 FreeBSD 提供了 Git repository,翻了一下看起來是最近在切換,這邊有翻到慣例的 HEADS UP:「HEADS UP: FreeBSD changing from Subversion to Git this weekend」。

The FreeBSD project will be moving it's source repo from subversion to git starting this this weekend. The docs repo was moved 2 weeks ago. The ports repo will move at the end of March, 2021 due to timing issues.

大概是 2008 年先把 src tree 從 CVS 換到 Subversion 上:「FreeBSD src 部份由 CVS 轉換到 Subversion」。

然後 2012 年把 ports tree 換過去:「FreeBSD ports 將從 CVS 轉移到 Subversion 上...」。

雖然已經很久沒用 FreeBSD 了 (最近碰到最接近的系統應該是 pfSense),但還是先恭喜他們總算要切換了,兩邊的能量差太多了...

FreeBSD 12.2 在 AWS 的 Amazon EFS 整合 (autofs)

Colin Percival 提到了 FreeBSD 12.2 上 autofs 會整合 Amazon EFS,讓掛載進來變得更方便:「Some new FreeBSD/EC2 features: EFS automount and ebsnvme-id」。

用法是先設定 autofs,然後啟用 autofs:

# echo '/efs -efs' > /etc/auto_master 
# sysrc autofs_enable="YES"

然後重開機後就可以直接切到 /efs/FSID 把 EFS 掛起來了:

Having done this, any access to the path /efs/FSID (e.g., /efs/fs-01234567) will automatically and transparently mount that filesystem.

另外加上原來對 EBS 與 ephemeral disk 的支援,這樣 storage 的部份算是該有的都有了:

Using the tool and some devd magic, FreeBSD now maintains a tree under /dev/aws/disk containing the symlinks of the forms

  • /dev/aws/disk/ebs/vol-0123456789abcdef
  • /dev/aws/disk/linuxname/sdh
  • /dev/aws/disk/ephemeral/SERIALNO

勸人從 Linux 跳到 FreeBSD 的戰文...

前幾天在 Facebook 上看到正妹朋友的貼文,然後在 Hacker News Daily 上也看到了:「Technical reasons to choose FreeBSD over GNU/Linux」。

標準的戰文 XDDD

在這篇講的是 FreeBSD 在技術上的優勢 (雖然我覺得很多不是優勢...),作者在一月的時候有另外兩篇在講 BSD (不只是 FreeBSD) 與 Linux,主題偏政治面 (包括了社群的運作方式) 與 license 之類的問題,也是戰文:「Why you should migrate everything from Linux to BSD」與「Why you should migrate everything from Linux to BSD - part 2」。

不過畢竟就是戰文,拿爆米花來吃就好,還是用的順手比較重要。當初 FreeBSD 的 issue tracking system 換掉以後,覺得太卡就抽手了,不然還蠻愛 Ports 的架構的...