從1納秒到2天：你的系統延遲「合理」嗎？

2024-07-16三農

雲算計（ID：gh_0068c4e23a81），作者：曹亞孟，原文標題：【從1納秒到2天，談IT系統的延遲指標】，題圖來自：視覺中國

前言一、為什麽要談延遲

我一直就想寫一篇技術分析文章，介紹從1納秒開始，IT系統內經歷了多少次剎那芳華、多少種白駒過隙。最近看了一本談IT技術架構的電子書（thebyte.com.cn），其2.1章節就是「了解各類延遲指標」，我一時技癢，決定寫下這篇文章。

了解掌握IT系統中各種常見動作的延遲指標，並不是賣弄技巧和炫耀專業性。這些延遲指標， 和效能調優、流程和資源最佳化都有著巨大的關聯： 各種技術評估和產品設計，都必須符合IT時延的自然規律。

產品最佳化、技術評估的方法論必須和IT技術常識結合，才能做出有可行性的判斷和行為。比如，因為有光速限制，且北京到廣州的直線距離是1800km， 我們就算再舍得砸錢買器材，也不可能讓北京到廣州的延遲低於6毫秒。

前言二、模糊指標也夠用

限於篇幅和時間原因，本文對這些延遲指標也並未特別嚴謹的考證，特別是納秒和微秒區的延遲，更是缺乏相關資料。還好我手頭有本拆解作業系統的紙質書，也有通義千問這類AI幫我找數據。

這些「延遲指標」並沒有明確的定義規範，有些指標只是一兩個具體的軟硬件動作，而有些延遲指標是一套完整的邏輯事件，所以這些延遲指標只有「參考價值」，但沒有明確的「可比性」。

這些模糊參考的延遲指標做科普，就足以規避一些離譜的設計問題。比如我們做個時延排序： 納秒級記憶體<微秒級網絡<毫秒級硬碟<20毫秒級HTTP介面。 無論具體數值是否精確，這幾個時延的差值都是十倍以上的。

脊椎動物能稱霸生物圈的訣竅就是「巨大且靈活的體型」，而節肢動物、軟體動物體型一變大就會運動緩慢。脊椎動物祖上積德，演化出了包裹了髓鞘的神經，訊號傳輸速率是節肢和軟體動物的100倍。我們人類保持著接近2米的巨大體型，靠低延遲神經指揮，可以靈活出掌打死體型幾毫米的蚊子。

一、低於20納秒

只有CPU能保持20納秒以下的延遲，99%的工作沒資格埋怨CPU的速度慢。

物理學中對時間的定義有個最小尺度，叫做「普朗克時間」，意為科學範疇內不存在比其更短的時間尺度了。IT系統中的「普朗克時間」，就是「CPU時鐘周期」。用1秒鐘（1G納秒）除以CPU的主頻就能得到CPU的時鐘周期，一般CPU的主頻約為3G左右，所以IT系統中的最短時間周期約為0.3納秒。

CPU需要從寄存器、一級緩存、二級緩存、三級緩存中讀取數據才能進行計算，CPU計算的內容也不止步於「與或非簡單運算」，還會做一些分支預測和加鎖解鎖。這些工作的延遲約為1—20納秒，且受到不同架構、不同硬件、不同指令集和編譯器的影響。這1—20納秒的速度確實拖了CPU的後腿，但和後續各種微秒、毫秒的工作比，簡直是快如閃電。

我對GPU硬件的了解不多，據說NVLink C2C介面的連線延遲能達到5納秒，確實只有這麽低的延遲，才能保證CPU和GPU同時操作記憶體時的數據一致性。

99%的應用程式只要沒有Bug、沒弱雞到汗顏的垃圾程式碼，都不會觸發CPU的效能瓶頸。 我工作中遇到特別消耗CPU的任務，多是科學計算、即時生成3D共享地圖的遊戲伺服端、編解碼這類業務。

二、20到500納秒

只有主機板總線、記憶體、PCIE介面能保持500納秒以下的延遲，作業系統也開始關註這個延遲量級的行為動作。

不同主頻、不同世代的記憶體，其存取時延會有一定的差異，日常做科普預估時，CPU透過總線存取記憶體的時延約為80到100納秒。

PCIE5.0介面本身的存取時延能控制在50納秒左右，但是這僅僅是介面自身的時延，介面對端的器材可能速度很快或者很慢。當PCIE介面對接GPU時，讀寫延遲就是50納秒，但對接一塊網卡或者SSD時，讀寫延遲就是微秒級了。

作業系統玩來玩去，關註的就是CPU、記憶體和IO介面。 因為記憶體和IO介面能達到50到100納秒的存取速度，所以作業系統發起系統呼叫的時間，也能控制在500納秒以內。註意這僅僅發起系統呼叫的時間，並不代表呼叫成功或者超時失敗。Linux系統中可設定的行程時間片最小長度約為CPU時鐘周期的100倍，也大致能歸結到該時間周期內。

三、1到20微秒

在1到20微秒的區間裏， 我們已經可以完成記憶體讀寫、網絡封包和大部份系統呼叫。

當在同一個行程內操作同一份記憶體數據時，比如從記憶體中順序讀取1MB數據，大約需要3微秒，且隨著記憶體工藝的進步，該時間還在減少。我們做各種效能最佳化時，只要把負載從硬碟挪到記憶體，效能就有大振幅提升，就是因為是記憶體的尋址定位和讀寫速度，比SSD要快上十倍，比機械硬碟要快上數百倍。

對於和記憶體操作強相關的系統呼叫，比如行程控制、記憶體管理，都可以在10微秒內完成。 前言第二段已經提到，既然有基於網絡的分布式塊儲存，為什麽沒有基於網絡的分布式記憶體？因為作業系統處理缺頁中斷時，留給分配記憶體的時間視窗只有幾微秒，如果依賴網絡做了個「分布式記憶體」，肯定會系統等待超時，然後OOM kill掉這個行程。

網卡將數據封包後發到網線、將光電訊號轉化為封包都有延遲。普通乙太網路卡的延遲超過了15微秒，RDMA（InfiniBand）網卡的操作延遲大約是2微秒，RDMA（RoCE）網卡的操作延遲也可以低於5微秒。因此客戶在必須在GPU群集裏做分布式視訊記憶體池時，只能采用昂貴的RDMA網絡。此外，據說某些雲廠商還在研發速度更快的網卡。

四、20到500微秒

在20到500微秒這個時間段裏，終於開始出現一些讀者們更熟悉、更容易觀測的角色了，比如 系統上下文切換、SSD磁碟機隨機讀寫、同數據中心的內網延遲、記憶體型數據庫的常規查詢速度。

從工程師的視角看，此時此刻終於是可觀測的了。無論是作業系統還是一些應用程式，它們的時間戳都可以記錄到微秒。我們做系統調優開始關註上下文切換的頻率，下文提到的ping測的時間戳就是微秒，Redis的慢查詢定義標準也是微秒。

SSD磁碟機的隨機讀取數據時，定位到數據的延遲大約是15微秒，從SSD磁碟機順序讀取1M的數據，用時不超過50微秒。 SSD磁碟機微秒級的響應速度，和傳統SATA磁碟機毫秒級的響應速度，完全就不是一個量級。因此可以引出一個梗頭：15年前的DBA經常在最佳化機械硬碟的磁頭，但是隨著SSD的普及，大量數據庫最佳化工作直接消失了。

同數據中心的內網延遲，一般能控制在500微秒以下。在公有雲語境中，同可用區兩台雲主機互ping，可以觀測到不超過500微秒的延遲。已知每一次網卡收發都有幾微秒到十幾微秒的延遲，一條鏈路要經過多台交換機，外加VPC封包解包也有延遲，這個測試數值就是相對合理的。請註意，VPC網絡內經常使用分布式閘道器，如果雲主機ping測閘道器，可能是本宿主機的OVS代為應答了，延遲會低於100毫秒。

記憶體型數據庫和基於SSD磁碟機的數據庫做一些常規查詢操作，比如在小數據庫裏內查詢很短的Key值，其操作過程就是從記憶體中讀取數據，然後給讀到的數據加個簡單的包頭包尾，這個過程只有幾十微秒。Nginx在已經建立的連結中，解析一個簡單的HTTP請求，也能達到這個延遲標準。

五、0.5到10毫秒

存取時延符合0.5到10毫秒的IT行為很多，但常見的就三大類： 無線區域網路、機械硬碟和同城網絡。

按照5G網絡的定義標準，其5G空口延遲需要低於1毫秒。（「空口」就是「空中介面」，就是「空氣版網線」加上天線網卡）。Wifi網絡的標準版本很多，我的電腦和Wifi5路由器實測的連線延遲在10毫秒左右。 一個關註網絡延遲的套用， 使用者直接用5G網絡就會比用Wifi的速度更快。

2019年推出5G網絡時，很多人把低時延當做重大產品賣點，但是大部份網絡套用不太在意5G空口節省的10毫秒延遲，所以我們一直沒找到爆款5G套用。

機械硬碟的尋址速度，理想化情況下是2毫秒，但實測經常能到10毫秒。當服務程式需要機械硬碟做讀寫定位操作時，無論操作的數據量有多小，都要做好10毫秒延遲的準備。依賴機械硬碟的數據庫或大數據群集，其查詢操作被機械硬碟拖累，通常延遲會達到10毫秒以上。但這些重IO負載的套用一般會頻繁讀寫大量數據，所以就會只計算IO頻寬，不會刻意關註讀寫延遲了。

我的書中介紹IaaS雲產品時，多次提到同Region不同AZ的概念。AZ有兩種，第一種是同一地域、未必能錯開供電的AZ，這種AZ的直線距離很近，延遲不超過3毫秒；第二種AZ是同城但不同地域，錯開了上遊電站的AZ，這種AZ的延遲約為3到10毫秒。本地Region和本地CDN覆蓋的個人使用者，也能達到10毫秒以內的網絡延遲。

六、10到440毫秒的網絡延遲

IT系統中大於10毫秒的技術延遲， 最常見的就是廣域網路通訊延遲。 網卡封包只是個微秒級操作，所以網絡延遲主要受限於光速和實際網絡拓撲的長度。客戶看似無法承受一點點的網絡延遲，但那都是被供應商慣出來的，其實大家都能承受很高的網絡延遲。

光纖中的光速是每秒鐘20萬公裏，但因為網絡拓撲不是直線，轉發器材也比較多，所以我們做網絡延遲預估時，無論是雲內同Region裸纖、常規網絡覆蓋還是普通的長途專線，一般都可以按照 「直線距離每增加50公裏就增加1毫秒延遲」 進行延遲估算。也有極少數例外，比如 跨大洋海纜布設時走直線、轉發器材也比較少，所以傳輸速度超過了每毫秒50公裏。

廣域網路通訊主要影響到的是客戶端自然人的感受。常規的網絡套用，比如存取網頁、線上交易、棋牌遊戲、追劇、看直播，可以認為是對網絡延遲沒有要求，100毫秒延遲的頻寬足以覆蓋全國。對於人跟人之間快速互動的業務場景，比如競技網遊、雲遊戲雲桌面、影片會議，客戶能流暢互動的時間周期約為80毫秒。這個互動周期包括客戶端計算、伺服端計算、兩次網絡往返傳輸數據，一般留給網絡延遲的時間約為20毫秒。

雖然廠商都在宣傳影片會議不卡頓，但那是在北上廣之間不卡頓。 如果連麥雙方必須保持很遠的物理距離（比如中美、中歐），使用者也就習慣了數百毫秒的高延遲。

結合上面兩種需求，如果我們將網絡延遲限定在20毫秒，在北京、上海、廣州、武漢、成都、沈陽、西安畫幾個1000公裏的大圓圈，這幾個圓圈足覆蓋90%的國內網民，延遲也足以滿足99.9%的業務需求。大家習慣用CDN加速，主要不是為了降低網絡延遲，而是因為CDN頻寬的價格比BGP頻寬更便宜。各種CDN比延遲大賽，其實是雲廠商在盲目內耗。

當使用者能接受網絡延遲大於100毫秒時，我們就可以用一國網絡來覆蓋全球了。 距離中國最遠的國家是阿根廷，2.2萬公裏的距離就是440毫秒的延遲。對於看影片、看網頁、文字聊天、棋牌遊戲這類需求來說，440毫秒的延遲並非不能接受，大家不信的話可以開啟阿根廷的網站看一看。

東數西算的西部節點，本來因為天然的延遲問題，只能定位成價格偏低的冷備節點。但是國運來誰都擋不住， 對話式大模型的互動過程不要求快速即時響應，這些電費便宜網絡緩慢的西部節點，突然就能扛起線上即時業務的重擔了。

七、大於10毫秒的連線延遲

上一節的內容太多了，所以我將大於10毫秒的連線延遲單獨整理成了一個章節。大家看下文內容也能發現，延遲超過10毫秒的業務，大多是被網絡傳輸延遲拖累的。

TCP是嚴謹的有狀態協定， 客戶端需要三次握手才能和伺服端建立連結，每次握手都要加上一次網絡延時。 在健康穩定的網絡裏，建立一次TCP連結需要50到200毫秒，而在劣質網絡中（比如4G訊號時斷時續的地鐵裏），建立一個TCP連結可能需要幾秒鐘。TLS加密協定（前身是SSL協定）一般也是基於TCP協定進行通訊，所以TLS一次握手也需要同樣漫長的時間。

相比之下，UDP傳輸資料包沒有握手過程，客戶端直接對著伺服端拋數據就行了，UDP相比TCP天然節省60%的網絡延遲。這些年很多輕量級創新通訊方式（比如Quic、WebRTC、DTLS和一些IOT協定），就是在用UDP取代TCP，那些原本由TCP完成的校驗和流控等工作，統統改由套用層自行完成。

DNS解析既可以基於TCP也可以基於UDP，且在本網絡乃至本機由多級緩存，所以DNS的解析時間能控制在50毫秒以內。但HTTP_DNS本質上是HTTP，且一般做了TLS加密，其解析速度就要參考TCP的通訊延遲了。

除了廣域網路傳輸延遲之外，也有一種常見的遷移凍結延遲。 當雲廠商需要「無縫遷移」雲主機時，需要在雲主機遷移的瞬間凍結系統，以保證新舊主機的記憶體一致性。 這個遷移操作並不是完全真的無縫無感，而是會導致雲主機的系統hang機100到200毫秒，而雲主機內的GuestOS很難感知到時間被暫停過的。

八、從1秒到2天

從1秒鐘秒到2天，這些時間刻度屬於工程師們關註的範圍，這些工作和產品設計的關聯不大，但當我們面對各種技術實施工作時，就需要掌握從1秒到2天的種種IT時刻，才能避免違背常識為難工程師。

在宿主機上冷啟動一個常規容器，需要花費1到5秒的時間；如果將一台雲主機重新開機，需要花費5—10秒時間；如果新建一台雲主機，需要5到15秒時間。在關閉記憶體校驗、跳過磁盤檢查的情況下，如果一台物理伺服器重新開機或冷啟動，需要花費30到120秒的時間。因為很多IT服務的健康檢查周期是5到30秒，所以重新開機雲主機和重新開機物理機的影響並不相同。

自動監控系統發現故障的時間一般為15到90秒，這個告警閾值不能設定的比15秒更短，太短的告警閾值會頻繁的觸發誤報，最終導致工程師忽略真正的故障。參照一些SRE技術執行標準，1分鐘發現故障、5分鐘定位故障、10分鐘解決故障就是自然人工程師幹預故障的生理極限了。

雲廠商采購的機櫃、頻寬這類雲資源，一般就是99.9%的SLA，這代表著全年允許故障時間是8.6小時； 雲廠商將不穩定的資源包裝成雲產品後， 一般對外承諾99.95%的SLA，全年允許故障時間是4.3個小時。 最貴的硬件保修是維保方承諾4小時內（連堵車都考慮到）帶著備件到機房現場替換，雲廠商一般采購的是「報修後下一工作日上門」服務，但也有更便宜但速度更慢的批次寄修維保服務。

海外網絡維護時，網絡工程師需要經常調整BGP路由廣播。這個調整工作一般需要等待24小時路由生效、再觀察24小時確認調整效果，做一次調整的累計時間至少2天。所以讀者朋友們不要看到海外頻寬可以自主發送BGP廣播，就誤以為調整網絡是個很簡單的高頻操作。

結束語

寫清楚這些延遲、讀這篇文章，都不是太容易的事，但有難度也有用途的知識，才更有含金量啊。

為了撰寫本文，我特地完整的讀了一本談系統原理的書；我借助了AI搜集了很多相關資訊，但AI給的答案，我都要再覆核檢查來源資訊網頁。

我很清楚，至少90%的產品經理不知道自家產品的常見動作響應延遲。但我們也莫笑產品經理是水貨，因為90%的程式設計師也不關註自己寫的軟件有多高的存取延遲。

但這個工作非常有用，當我們對一個IT服務提出有可行性的效能需求時，或者要在效能不變的前提下做成本最佳化時，都需要掌握了解這些和效能有關的延遲資訊。