看進程小 P 講述它的網絡性能故事!
本文轉載自微信公眾號「開發內功修煉」,作者張彥飛allen 。轉載本文請聯系開發內功修煉公眾號。
大家好,我是飛哥!
今天給大家帶來的是一個漫畫故事!
01
大家好,我是一個進程,我的名字的小 P。
我和很多其它小伙伴一樣,都由老大操作系統創建和管理。
要問我是怎么來的,噓小點聲,不能讓那幫應用開發們聽見。
其實就是內核的開發都認為應用開發是傻逼,怕應用開發的代碼把服務器給搞壞。就設計了我們進程出來,專門運行各種用戶態的代碼。
我們天然和內核里的小伙伴們被隔離開來。我們大部分時間都運行在用戶態,其它的兄弟們都一直運行在內核態。
我們沒有權限訪問硬盤、網卡等設備。
如果我們需要這些功能的時候,需要通過系統調用先陷入到內核態中。不過在陷入之前,系統調用入口要對我們執行嚴格的安檢。
好了背景就是這樣,今天我給大家講講我和我的好朋友們之間是怎么配合處理網絡IO的。
02
我們進程通過一個叫 socket 的哥們來和我們的用戶通信。但是實際上所有的 socket 以及整臺機器上的網絡包都是在內核態來把控著的,我們只能拿到 socket 的編號。
在很久很久以前,我們一般只處理一條 TCP 連接。
我們通過一個叫 recvfrom 的系統調用來讀取我們的用戶發送過來的數據。假如運氣好的話,我們 recvfrom 的時候就可以把數據取走!
但是其實根本我們不知道用戶那邊啥時候給我們打數據包過來,所以大部分情況下都不會運氣那么好。
如果 read 的時候數據包沒有就緒,我們就得按照規矩主動把 CPU 讓出來。
不過那時我們也確實只處理一條連接,連接上沒請求被阻塞掉也正常。
后來老板不斷的壓榨我們,讓我們一個進程處理成百上千條連接。這時候 read 某條連接的時候,沒有數據就把我們掛起來,我們哪兒受得了哇, 我們還有其它好多連接要處理呢。
而且頻繁的阻塞導致我的工作效率特別低下。 第一我們阻塞要花不少的時間保存我們當前的工作狀態,第二我們在 L1/L2/L3 等 cache 里準備了好多工作時要用的緩存這下全沒用了。
后來我們就給操作系統老大求了個情,要求把連接設置成非阻塞。
我:“哥,我只是來看看這條連接上有沒有數據哈,有就給我,沒有也別阻塞我可以不?”
操作系統:“準!”
這下就好了,我就可以用循環遍歷的方式把我所有的 socket 挨個到內核中去看一遍。
但是我的問題是我還是不知道用戶啥時候把數據發過來。如果沒有就緒的,那我只能就頻繁循環地不斷地來內核詢問。
“去看看 1 號 socket 上有數據了沒?” “沒有”
“去看看 2 號 socket 上有數據了沒?” “沒有”
“去看看 3 號 socket 上有數據了沒?” “沒有”
...
“去看看 1 號 socket 上有數據了沒?” “沒有”
“去看看 2 號 socket 上有數據了沒?” “沒有”
“去看看 3 號 socket 上有數據了沒?” “終于有啦”
干這事可特么把我累壞個屁的了,運氣不好的時候我得訪問成千上萬次才能等到數據真正到來!
03
終于!!!
后來操作系統老大在內核態搞出了各種支持多路復用的新系統調用,它們是 select、poll、和 epoll。
不過嘿嘿,我最喜歡 epoll 這個新家伙。
我把需要觀察的 socket 都交給他,他替我都維護了起來了,據說是內部用了一個叫啥紅黑樹的高深技術。
不過其實愛用啥用啥,我只關注能解放我的體力就行。
我是終于不用再不斷的輪詢了,每次我想要知道哪個 socket 上有請求的時候,直接進入內核態查看一下就緒隊列就行了。
這種爽歪歪的感覺,你們真的無法體會。這就是我喜歡用這個家伙的原因。
如果請求很多,那我就可以一直 epoll_wait 獲取請求,一直處理,而不用阻塞。
直到時間片耗盡被再次丟到就緒隊列等待調度。
我的工作效率發揮到了極致,能處理的并發也越來越多。
在 redis 上,我最高能達到每秒 10W 的qps,怎么樣厲害吧!
不過在所有的連接上都沒有數據的時候,我也需要阻塞起來。
這個我是接受的,畢竟沒活兒干的時候還占著 CPU 資源,我也會覺得怪不好意思。
等網卡收到我的數據請求包的時候,我的另外一個兄弟軟中斷會從 epoll 的 wq 上找到我,把我叫醒。
不過我所謂的叫醒,其實只是推入到就緒隊列而已。真正的調度還得等進程調度器老哥把我拉起來。
看,我和 epoll、軟中斷、進程調度器等幾兄弟配合的是不是天衣無縫!
結語
理解 epoll 這種內核級的技術會極大地提升你的內功能力。之前飛哥從源碼級別講了一遍,反響非常不錯,在一萬粉的情況下竟然達到了 5000 的閱讀數。