最近做了一些系統和網路調優相關的測驗，達到了期望的效果，有些感悟，同時，我也發現知乎上對Linux服務器低延遲技術的討論比較欠缺（滿嘴高并發現象）；或者對現今cpu + 網卡的低延遲潛力認識不足（動輒FPGA現象），比如一篇知乎高贊的介紹FPGA的文章寫到“從延遲上講，網卡把資料包收到 CPU，CPU 再發給網卡，即使使用 DPDK 這樣高性能的資料包處理框架，延遲也有 4~5 微秒，更嚴重的問題是，通用 CPU 的延遲不夠穩定，例如當負載較高時，轉發延遲可能升到幾十微秒甚至更高”，剛好我前幾天做過類似的性能測驗，發現一個tcp或udp的echo server可以把網卡到網卡的延遲穩定在1微秒以內，不會比FPGA方案慢很多吧？
因此，我覺得有必要分享下自己的見解，總的來說，我打算分兩篇文章討論相關低延遲技術：
1）系統調優（本文）：一些低延遲相關的Linux系統設定，和一些原則，
2）網路調優：使用solarflare網卡降低網路IO延遲，
這里不打算介紹用戶空間的延遲優化，因為太廣泛了，另外我之前的文章也分享一些解決某類問題的低延遲類別庫，
說到低延遲，關鍵點不在低，而在穩定，穩定即可預期，可掌控，其對于諸如高頻交易領域來說尤為重要， 而說到Linux的低延遲技術，一個不能不提的詞是"kernel bypass"，也就是繞過內核，為什么呢？因為內核處理不僅慢而且延遲不穩定，可以把作業系統想象成一個龐大的框架，它和其他軟體框架并沒有什么本質的不同，只不過更加底層更加復雜而已，既然是框架，就要考慮到通用性，需要滿足各種對型別用戶的需求，有時你只需要20%的功能，卻只能take all，
因此我認為一個延遲要求很高（比如個位數微秒級延遲）的實時任務是不能觸碰內核的，（當然在程式的啟動初始化和停止階段沒有個要求，That's how linux works）， 這里的避免觸碰是一個比bypass更高的要求：不能以任何方式進入內核，不能直接或間接的執行系統呼叫(trap)，不能出現page fault(exception)，不能被中斷(interrupt)，trap和exception是主動進入內核的方式，可以在用戶程式中避免，這里不深入討論（比如在程式初始化階段分配好所有需要的記憶體并keep的物理記憶體中；讓其他非實時執行緒寫日志檔案等），本文的關鍵點在于避免關鍵執行緒被中斷，這是個比較難達到的要求，但是gain卻不小，因為它是延遲穩定的關鍵點，即使中斷發生時執行緒是空閑的，但重新回到用戶態后cpu快取被污染了，下一次處理請求的延遲也會變得不穩定，
不幸的是Linux并沒有提供一個簡單的選項讓用戶完全關閉中斷，也不可能這么做（That's how linux works），我們只能想法設法避免讓關鍵任務收到中斷，我們知道，中斷是cpu core收到的，我們可以讓關鍵執行緒系結在某個core上，然后避免各種中斷源（IRQ)向這個core發送中斷，系結可以通過taskset或 sched_setaffinity實作，這里不贅述， 避免IRQ向某個core發中斷可以通過改寫/proc/irq/*/smp_affinity來實作，例如整個系統有一塊cpu共8個核，我們想對core 4~7屏蔽中斷，只需把非屏蔽中斷的core(0 ~ 3)的mask "f"寫入smp_affinity檔案，這個操作對硬體中斷（比如硬碟和網卡）都是有效的，但對軟中斷無效（比如local timer interrupt和work queue），對于work queue的屏蔽可以通過改寫/sys/devices/virtual/workqueue/*/cpumask來實作，本例中還是寫入"f"，
那么剩下的主要就是local timer interrupt(LOC in /proc/interrupts)了，Linux的scheduler time slice是通過LOC實作的，如果我們讓執行緒獨占一個core，就不需要scheduler在這個core上切換執行緒了，這是可以做到的：通過isolcpus系統啟動選項隔離一些核，讓它們只能被系結的執行緒使用，同時，為了減少獨占執行緒收到的LOC頻率，我們還需要使用"adaptive-ticks"模式，這可以通過nohz_full和rcu_nocbs啟動選項實作，本例中需要在系統啟動選項加入isolcpus=4,5,6,7 nohz_full=4,5,6,7 rcu_nocbs=4,5,6,7 來使得4~7核變成adaptive-ticks，adaptive-ticks的效果是：如果core上的running task只有一個時，系統向其發送LOC的頻率會降低成每秒一次，內核檔案解釋了不能完全屏蔽LOC的原因："Some process-handling operations still require the occasional scheduling-clock tick. These operations include calculating CPU load, maintaining sched average, computing CFS entity vruntime, computing avenrun, and carrying out load balancing. They are currently accommodated by scheduling-clock tick every second or so. On-going work will eliminate the need even for these infrequent scheduling-clock ticks."，
至此，通過修改系統設定，我們能夠把中斷頻率降低成每秒一次，這已經不錯了，如果想做的更完美些，讓關鍵執行緒長時間（比如幾個小時）不收到任何中斷，只能修改內核延長中斷的發送周期，不同kernel版本相關代碼有所差異，這里就不深入討論，不過大家可能會顧慮：這樣改變系統運行方式會不會導致什么問題呢？我的經驗是，這有可能會影響某些功能的正常運轉（如內核檔案提到的那些），但我尚未發現程式和系統發生任何例外，說明這項內核修改至少不會影響我需要的功能，我會繼續使用，
兩個原則：
1）如果一件事情可以被delay一段時間，那它往往能夠被delay的更久，因為它沒那么重要，
2）不要為不使用的東西付費，對于性能優化來說尤為如此，
如何檢測中斷屏蔽的效果呢？可以watch/proc/interrupts檔案的變化 ，更好的方法是用簡單的測驗程式來驗證延遲的穩定性：
#include <iostream>
uint64_t now() {
return __builtin_ia32_rdtsc();
}
int main() {
uint64_t last = now();
while (true) {
uint64_t cur = now();
uint64_t diff = cur - last;
if (diff > 300) {
std::cout << "latency: " << diff << " cycles" << std::endl;
cur = now();
}
last = cur;
}
return 0;
}
通過taskset系結一個核運行程式，每進入一次內核會列印一條資訊，
最后，除了進入內核以外，影響延遲穩定性的因素還有cache miss和tlb miss，
對于減少cache miss，一方面需要優化程式，minimize memory footprint，或者說減少一個操作訪問cache line的個數，一個快取友好例子是一種能高速查找的自適應哈希表文章中的哈希表的實作方式，另一方面，可以通過分(lang)配(fei)硬體資源讓關鍵執行緒占有更多的快取，比如系統有兩塊CPU，每塊8核，我們可以把第二塊CPU的所有核都隔離掉，然后把關鍵執行緒系結到其中的部分核上，可能系統只有一兩個關鍵執行緒，但它們卻能擁有整塊CPU的L3 cache，
對于減少tlb miss，可以使用huge pages，
鏈接：https://pan.baidu.com/s/1v5gm7n0L7TGyejCmQrMh2g 提取碼：x2p5
免費分享，但是X度限制嚴重，如若鏈接失效點擊鏈接或搜索加群 群號744933466，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/84898.html
標籤：C++