netflix

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 的機器啊...

Netflix 在 2013 年 Open Connect Appliances

Reddit 上的原文在「So I got a Netflix cache server...」這邊，但看起來作者自己刪掉內容了 (可能是被接觸要求刪掉？)，可以看 Internet Archive 上的「20221026080226」，以及報導「How a Redditor Ended Up With an Industrial-Grade Netflix Server」。

所以是 Netflix 退役的機器，看起來適合法取得的？

I work for a large ISP, and we are retiring/replacing quite a few 2013 era Netflix OCA caches, and I was offered one. Of course, I couldn't say no 😅

資料當然是被清過的：

I knew that Netflix had wiped them all in the decommissioning process, that they ran FreeBSD, that they were crammed full of drives, and that's about it.

然後這台 2013 年的機器以現在的角度來看也算很大台，尤其是看到硬碟的部份是 36 顆 HGST 的 7.2TB 硬碟：

36x 7.2TB 7200RPM HGST's

再加上 4 個 10Gbps 的界面可以接：

One 4x 10G SFP+ NIC

作者後來裝了 TrueNAS 來用，就這些規格資料看起來的確是個很適合當 NAS：

I expected some resistance when trying to install an OS, but it was already set to boot from USB and took a TrueNAS install like a champ!

但不確定會吃多少電，放在家裡用還是得考慮這點... 不然就是當紀念品收起來。

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 也有點極限的感覺了...

Brendan Gregg 加入 Intel

先前有提到 Brendan Gregg 離開了 Netflix 的事情：「Brendan Gregg 離開 Netflix」，剛剛看到他發表他去 Intel 的消息：「Brendan@Intel.com」。

看起來是任何跟 performance 有關的都可以碰，但主力會放在跟 cloud 相關的產品線上：

I'm thrilled to be joining Intel to work on the performance of everything, apps to metal, with a focus on cloud computing.

不知道起頭會碰什麼東西，也許先花幾個月熟悉？

Brendan Gregg 離開 Netflix

Brendan Gregg 宣佈離開 Netflix：「Netflix End of Series 1」，Hacker News 上他也有跳出來回答一些問題：「Netflix End of Series 1 (brendangregg.com)」。

看到有些問題還蠻有趣的，像是被問到桌子的大小：

Off topic: I’m a bit surprised about Gregg’s desk (pre-pandemic). I imagine he’s getting a top level salary at Netflix but yet he’s got a small desk in what it looks to me a shared small office (or perhaps is that a mini open space office? Can’t tell).

大概是在文章裡面有圖，所以被問：

他的回答：

A number of times people have asked about my desk over the years, and I'm curious as to why! I've visited other tech companies in the bay area, and the desks I see (including for 7-figure salary engineers) are the same as everyone else, in open office layouts. At Netflix it's been open office desks, and all engineers have the same desk.

Does some companies give bigger desks for certain staff, or offices, or is it a country thing (Europe?).

目前還沒有提到下一份工作是什麼：

I'll still be posting here in my next job. More on that soon...

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

Cloudflare 與 ISP 合作推出 ODoH 加強隱私，然後 Google 想要看 HTTPS 流量

Cloudflare 推出了 ODoH (目前是 IETF 的 draft：「Oblivious DNS Over HTTPS」)：「Improving DNS Privacy with Oblivious DoH in 1.1.1.1」，在 Hacker News 上面也有討論：「 Improving DNS Privacy with Oblivious DoH (cloudflare.com)」

基本上就是 DNS over HTTPS 在上面架一層 Proxy，但這層 Proxy 不能是 Cloudflare 自己：

Colin Percival 希望 AWS 有 us-chaos-1 (us-fail-1？)

在 Daily Hacker News 上看到的東西，這個網站會每天會演算法整理出 Hacker News 上十則消息 (就如同名字)，對於還不錯，這次有趣的是這個網站的作者 Colin Percival 自己在 Twitter 上講的東西也被收進去了...

他目前的主力服務應該是 Tarsnap，主打的是只有使用者有 key 能解開的雲端加密備份服務。這個服務放在 AWS 上，所以才會有這則：

I want to have an AWS region where everything breaks with high frequency. EC2 networks dropping packets, EBS volumes hanging and failing, entire AZs dropping offline, etc. If it breaks 0.001% of the time in us-east-1, I want it to break 1% of the time in us-fail-1. #awswishlist

— Colin Percival (@cperciva) August 9, 2020

希望有個三不五時就壞掉的環境，可以確保平常在設計架構上就會考慮到不穩定性。

這讓我想到 Netflix 的 Chaos Monkey，可能還是不夠用？

機器層應該可以用 Chaos Monkey 搞定，網路層應該可以在 PF 或是 iptables 上面模擬出來？雖然每台都得設定就是了... 目前沒有想到好方法的應該是 EBS 與 cloud service 的部份 (像是 RDS)，也許前面架個很容易壞掉的 TCP proxy 模擬？

另外馬上就看到下面有幾個人在偷婊其他 cloud service XDDD

Test your thing on IBM cloud. You’re welcome.

— Emir Ercan Ayar (@eercanayar) August 9, 2020

Cloudflare 也推出自己的 Speed Test 服務

Cloudflare 推出了自己的 Speed Test 服務：「Test your home network performance」。

這個服務跟 Netflix 推出的 fast.com 類似，測試的是使用者端到 Netflix (或是 Cloudflare) 中間的速度，主要的目的還是公關 (PR)，所以看看就好，實際上用 Speedtest 測出來會比較有參考價值，而且可以選擇不同的點測試...

不過這讓我想到之前有人測出來遠傳會對偵測使用者要使用 Speedtest 測試時開放速限的情況 (像是「遠傳吃到飽只有 Speedtest 沒限速」這篇)，然後就有各種定時去打 Speedtest 觸發開放速限的方法...

目前好像只剩下這篇活著，內文提到的是 Android 上的方法，另外推文有人提到 iOS 下的方法：「[心得] 在Android破解遠X限速」，如果有遇到的可以用看看...

Netflix 找到的 TCP 實做安全性問題...

這幾天的 Linux 主機都有收到 kernel 的更新，起因於 Netflix 發現並與社群一起修正了一系列 Linux 與 FreeBSD 上 TCP 實做 MSS 與 SACK 的安全性問題：「https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md」。

其中最嚴重的應該是 CVE-2019-11477 這組，可以導致 Linux kernel panic，影響範圍從 2.6.29 開始的所有 kernel 版本。能夠升級的主機可以直接修正，無法升級的主機可以參考提出來的兩個 workaround：

Workaround #1: Block connections with a low MSS using one of the supplied filters. (The values in the filters are examples. You can apply a higher or lower limit, as appropriate for your environment.) Note that these filters may break legitimate connections which rely on a low MSS. Also, note that this mitigation is only effective if TCP probing is disabled (that is, the net.ipv4.tcp_mtu_probing sysctl is set to 0, which appears to be the default value for that sysctl).

Workaround #2: Disable SACK processing (/proc/sys/net/ipv4/tcp_sack set to 0).

第一個 workaround 是擋掉 MSS 過小的封包，但不保證就不會 kernel panic (文章裡面用語是 mitigation)。

第二個 workaround 是直接關掉 SACK，這組 workaround 在有 packet loss 的情況下效能會掉的比較明顯，但看起來可以避免直接 kernel panic...