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 這邊沒動作了,大概是沒什麼動力...

VirtualBox 7.0.0 出了

LWN 看到 VirtualBox 7.0.0 出了:「VirtualBox 7.0.0 released」,其中 Changelog 可以在「Changelog-7.0」這邊翻到。

Ubuntu 下的更新還算方便,先把 VM 都關掉,移除 virtualbox-6.1 後再裝 virtualbox-7.0,然後把 VM 開起來看看有沒有什麼問題。

在 Changelog 裡面看到這個,這些 3D support 不知道有支援到什麼程度:

Devices: Implemented new 3D support based on DirectX 11 (and DXVK on non Windows hosts)

我把 Enable 3D Acceleration 的選項打開後變成只能跑 1600x1200,本來 1920x1200 不能跑,所以只好又關掉...

另外是支援了 virtual TPM 可以掛進去:

Devices: Added virtual TPM 1.2 and 2.0 devices

然後以前 USB 裝置的支援是 proprietary software,現在放到 open source 版本裡面了:

Devices: The EHCI and XHCI USB controller devices are now part of the open source base package

目前用起來沒什麼大問題,繼續觀察看看。

Linux 無線網路的 RCE 洞

Hacker News 首頁上看到 Linux 無線網路的 RCE 漏洞:「Some remotely exploitable kernel WiFi vulnerabilities」,mailing list 的信件是這邊:「[oss-security] Various Linux Kernel WLAN security issues (RCE/DOS) found」。

裡面題到了五個漏洞,其中屬於 RCE 的是這三個:

  • CVE-2022-41674: fix u8 overflow in cfg80211_update_notlisted_nontrans (max 256 byte overwrite) (RCE)
  • CVE-2022-42719: wifi: mac80211: fix MBSSID parsing use-after-free use after free condition (RCE)
  • CVE-2022-42720: wifi: cfg80211: fix BSS refcounting bugs ref counting use-after-free possibilities (RCE)

第一個只寫「An issue was discovered in the Linux kernel through 5.19.11.」,但討論上看到說應該是 5.1+,第二個在 CVE 裡面有提到是 5.2+,第三個是 5.1+。然後已經有看到 PoC code 了...

對於用 Linux 筆電的人得等各家 distribution 緊急出更新;但有些無線網路設備不知道怎麼辦...

Canonical 推出 Ubuntu Pro

Canonical 推出了 Ubuntu Pro,個人用戶以及小型商業用戶可以免費安裝在五台機器上使用:「Canonical launches free personal Ubuntu Pro subscriptions for up to five machines」。

這次是 public beta,這代表進到正式版本的時候也許還會有變化:

Ubuntu Pro, the expanded security maintenance and compliance subscription, is now offered in public beta for data centres and workstations.

這次推出的 Ubuntu Pro 看起來包括了 ESM (但這邊沒有提到 ESM,而是提到了十年的安全更新);除了 ESM 以外,包括了更多 package 的安全更新,一併提供十年:

Ubuntu Pro (currently in public beta) expands our famous ten-year security coverage to an additional 23,000 packages beyond the main operating system.

Including Ansible, Apache Tomcat, Apache Zookeeper, Docker, Drupal, Nagios, Node.js, phpMyAdmin, Puppet, PowerDNS, Python 2, Redis, Rust, WordPress, and many more...

不過看起來的確就是將 ESM 擴大,這點在 Ubuntu Pro 的價錢的頁面上「Ubuntu Pro | plans and pricing」可以看到有提到 ESM。

但要注意 14.04 雖然有 ESM (照時程表算的話會支援到 2024 年),卻不在這次 Ubuntu Pro 提供的範圍,這次推出的 Ubuntu Pro 是 16.04 以及之後的版本才有:

Ubuntu Pro is available for every Ubuntu LTS from 16.04 LTS. It is already in production for large-scale customers offering global services.

然後本來的 Ubuntu Advantage for Infrastructure 這條產品線改名為 Ubuntu Pro (Infra-only):

Ubuntu Advantage for Infrastructure is now rebranded to Ubuntu Pro (Infra-only). The features and price have not changed.

目前手上沒有 16.04 的機器,等明年 2023 看看 18.04 的機器有沒有換到 20.04/22.04,如果沒有的話也許可以來玩看看...

Apple M1 上跑 Linux 的 GPU driver 會動了

Hacker News Daily 上看到「Native Linux GPU Driver for Apple M1 (twitter.com/linaasahi)」這個,講 Apple M1 上有 Linux GPU driver 可以用了,原文是 Twitter 上的推:

不過從 YouTube 的影片上可以看到就只是「會動」,還有不少 rendering bug,可以看到有時候會破格,但畢竟是開始支援了,後續如果有修到穩定的話,直接的好處應該就是把瀏覽器的 rendering 丟給 GPU 處理,就像 macOS 或是 Windows 上的情況。

月份傳回值 0 表示一月的考古

Hacker News 上看到「History of Zero-Based Months? (jefftk.com)」這篇,在考古為什麼常常看到 function 在傳回「月份」時是以 0 表示一月。從這篇提到的「Why is day of the month 1-indexed but the month is 0-indexed in C? (twitter.com/hillelogram)」則是 2020 年的討論。

在討論裡面有提到 hillelogram 的 tweet,裡面有個看起來算合理的考古過程...

試著用 Thread Reader 產生單頁 (讀起來會比較好讀),但不知道為什麼一直失敗,結果往 Internet Archive 翻資料,倒是有 2020 年當初生成出來的版本

另外還是列出原來第一則 tweet:

作者在研究這個題目的時候,馬上可以想到的是 C 語言裡面的月份就是 0-indexed,而其他程式語言都很有可能會是因為 C 語言的關係一路把這個特性繼承下去:

直接跳到最後面作者的猜測,他覺得可能是為了讓後續使用起來更方便的關係。

其他的欄位大多都是透過類似 sprintf("%d") 的方式直接輸出數字,所以用 1-indexed 讓人直接讀,而月份則會透過 array 來轉字串,所以用 0-indexes 讓程式轉:

So that's my best guess: the programmers were working with constrained resources and could optimize `asctime` tricky pointer arithmetic on the month and day-of-week, so made them 0-indexed. Day-of-month is just for displaying to the user, so is 1-indexed.

沒辦法確定,但就是一種猜測,看起來還蠻... 合理... 的?

從 Android (AOSP) fork 出來的 /e/

上個禮拜在 Hacker News 看到的「Review of /e/ – An Android Alternative For Mobile Phones」,在講 /e/ 這個從 AOSP 改出來的作業系統,主力在於「unGoogled」這件事情,避免任何資料傳回給 Google。Hacker News 上對應的討論在「Review of /e/ – Android-based alternative for mobile phones (thenewleafjournal.com)」這邊。

先看了一下運作方式,/e/ 的後面是 e Foundation,以非營利組織的方式經營。

LineageOS 的經驗來看,看起來有蠻多東西預先包好了,像是預掛了 microG 來模擬 Google Play Services 的服務與 API,這樣可以讓一些需要 Google Play Services 的服務可以跑 (但可以預期不會是完全相容)。

另外也有一些商業合作,所以市場上可以買到出廠就已經安裝 /e/ 的手機,讓一般使用者更容易上手。另外一條可以預期的路是自己刷 /e/,從「Smartphone Selector」這邊可以看到 /e/ 支援很多型號。

文章裡另外題到了其他的 AOSP fork,走不同的路線:

In addition to LineageOS, there are two forks focused primarily on security – GrapheneOS and CalyxOS. There is also Replicant, which appears to mostly support older devices at this time.

看起來弄個 Pixel 5a 或是舊一點的 Pixel 4a 應該是個還可以的方向,Google 自家牌的手機通常都是這些 distribution 優先支援的機種...

Netflix 的 Open Connect 機器往 800Gbps 推進

2021 年的時候曾經提過 Netflix 試著用單機推出 400Gbps 的流量 (用在 Netflix 的 Open Connect):「Netflix 在單機服務 400Gbps 的影音流量」,快一年後的目前,Netflix 的人已經成功推到接近 800Gbps 了:「Serving Netflix Video Traffic at 800Gb/s and Beyond」。另外在 Hacker News 上的討論「Serving Netflix Video Traffic at 800Gb/s and Beyond [pdf] (nabstreamingsummit.com)」也可以看看。

翻了一下投影片,最後衝到 720Gbps,主要是因為 NIC output drop,而非其他部份。

裡面還是把之前的故事也都講了一遍 (不然簡報的時間會太短?),如果有看過前面的內容可以快速看一下就好,這次新的東西從 page 89 開始:

  • Asynchronous Sendfile (2014)
  • Kernel TLS (2016)
  • Network-centric NUMA (2019)
  • Inline Hardware (NIC) kTLS (2022)
  • 800G initial results

最後面幾張投影片裡面有提到往 800Gbps 衝的硬體平台:

  • AMD (EPYC 7713 CPUs)
  • Dell (PowerEdge R7525)
  • Mellanox/NVIDIA (ConnectX-6 Dx NICS)
  • Intel (P5316 NVME)

下個目標不知道是什麼,看起來目前已經壓榨到 memory bandwidth 也有點極限的感覺了...

在 Ubuntu 20.04/22.04 下使用 18.04 的 chromium-browser

Ubuntu 20.04 之後包的 chromium 都是基於 snap 的方案,是個除了 Canonical 的人以外沒人愛的東西,所以大家都在找方法改回 .deb 的版本。

剛剛因為需要測試東西所以才需要找這個方案,發現有個還蠻有趣的解法,是拿 18.04 的 chromium-browser 的套件來裝,因為官方至少會支援到 2023/04:「Is it still possible to install Chromium as a deb-package on 20.04 LTS using some third-party repository?」。

一個 /etc/apt/sources.list.d/bionic-update.list

deb http://archive.ubuntu.com/ubuntu/ bionic-updates universe

另外一個 /etc/apt/preferences.d/chromium-deb-bionic-updates

Package: chromium-browser chromium-browser-l10n chromium-codecs-ffmpeg-extra chromium-codecs-ffmpeg 
Pin: release a=bionic-updates
Pin-Priority: 900

完全還是使用官方套件的解法,唯一的缺點大概就是到明年四月而已,但對要測試來說夠用了...