Netflix 單機 800Gbps 伺服器所使用的最佳化技巧
source link: https://blog.gslin.org/archives/2022/11/03/10941/netflix-%e5%96%ae%e6%a9%9f-800gbps-%e4%bc%ba%e6%9c%8d%e5%99%a8%e6%89%80%e4%bd%bf%e7%94%a8%e7%9a%84%e6%9c%80%e4%bd%b3%e5%8c%96%e6%8a%80%e5%b7%a7/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
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 的機器啊...
Related
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…
August 21, 2022In "CDN"
Netflix 對 sendfile() 在 TLS 情況下的加速
Netflix 對於寫了一篇關於隱私保護的技術細節：「Protecting Netflix Viewing Privacy at Scale」。 其中講到 2012 年的 Netflix Open Connect 中的 Open Connect Appliance (OCA，放伺服器到 ISP 機房的計畫) 只有單台伺服器 8Gbps，到現在 2016 可以達到 90Gbps： As we mentioned in a recent company blog post, since the beginning of the Open Connect program we have significantly increased the efficiency of our…
August 10, 2016In "Computer"
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 的標準，他們又要繼續煩惱... 有看到…
September 20, 2021In "CDN"
Leave a Reply
Your email address will not be published. Required fields are marked *
Comment *
Name *
Email *
Website
Notify me of follow-up comments by email.
Notify me of new posts by email.
To respond on your own website, enter the URL of your response which should contain a link to this post's permalink URL. Your response will then appear (possibly after moderation) on this page. Want to update or remove your response? Update or delete your post and re-enter your post's URL again. (Learn More)
Post navigation
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK