I/O多路復用:select, poll, epoll[整理文]

I/O多路復用問題的引出

當需要讀兩個以上的I/O的時候，如果使用阻塞式的I/O，那么可能長時間的阻塞在一個描述符上面，另外的描述符雖然有數據但是不能讀出來，這樣實時性不能滿足要求，大概的解決方案有以下幾種：

  • 使用多進程或者多線程，但是這種方法會造成程序的復雜，而且對與進程與線程的創建維護也需要很多的開銷。（Apache服務器是用的子進程的方式，優點可以隔離用戶）
  • 用一個進程，但是使用非阻塞的I/O讀取數據，當一個I/O不可讀的時候立刻返回，檢查下一個是否可讀，這種形式的循環為輪詢（polling），這種方法比較浪費CPU時間，因為大多數時間是不可讀，但是仍花費時間不斷反復執行read系統調用。
  • 異步I/O（asynchronous I/O），當一個描述符準備好的時候用一個信號告訴進程，但是由于信號個數有限，多個描述符時不適用。
  • I/O多路轉接（I/O multiplexing）（貌似也翻譯多路復用），先構造一張有關描述符的列表（epoll中為隊列），然后調用一個函數，直到這些描述符中的一個準備好時才返回，返回時告訴進程哪些I/O就緒。
    I/O復用可以監聽多個文件描述符，可以是socket文件描述符，也可以是普通文件描述符，如標準輸入等。了解文件描述符就緒的條件。
    select和epoll這兩個機制都是多路I/O機制的解決方案，select為POSIX標準中的，而epoll為Linux所特有的。

select

select機制剛開始的時候，需要把fd_set從用戶空間拷貝到內核空間，并且檢測的fd數是有限制的，由FD_SETSIZE設置，一般是1024。
檢測的時候，根據timeout，遍歷fd_set表，把活躍的fd(可讀寫或者錯誤)，拷貝到用戶空間， 再在用戶空間依次處理相關的fd。
select的缺點：

  • 每次調用select的時候需要把fd_set從用戶空間拷貝到內存空間，比較耗性能。
  • wait時，需要遍歷所有的fd，消耗比較大。
  • select支持的文件數大小了，默認只有1024，如果需要增大，得修改宏FD_SETSIZE值，并編譯內核（麻煩，并且fd_set中的文件數多的話，每次遍歷的成本就很大）。

poll

poll的實現和select非常相似，只是描述fd集合的方式不同，poll使用pollfd結構而不是select的fd_set結構，其他的都差不多。

epoll

epoll優點：

  • 支持一個進程打開大數目的socket描述符(FD)
    select 最不能忍受的是一個進程所打開的FD是有一定限制的，由FD_SETSIZE設置，默認值是2048。對于那些需要支持的上萬連接數目的IM服務器來說顯然太少了。這時候你一是可以選擇修改這個宏然后重新編譯內核，不過資料也同時指出這樣會帶來網絡效率的下降，二是可以選擇多進程的解決方案(傳統的 Apache方案)，不過雖然linux上面創建進程的代價比較小，但仍舊是不可忽視的，加上進程間數據同步遠比不上線程間同步的高效，所以也不是一種完美的方案。
    不過 epoll則沒有這個限制，它所支持的FD上限是最大可以打開文件的數目，這個數字一般遠大于2048,舉個例子,在1GB內存的機器上大約是10萬左右，具體數目可以cat /proc/sys/fs/file-max察看,一般來說這個數目和系統內存關系很大。
  • IO效率不隨FD數目增加而線性下降
    傳統的select/poll另一個致命弱點就是當你擁有一個很大的socket集合，不過由于網絡延時，任一時間只有部分的socket是"活躍"的，但是select/poll每次調用都會線性掃描全部的集合，導致效率呈現線性下降。但是epoll不存在這個問題，它只會對"活躍"的socket進行操作---這是因為在內核實現中epoll是根據每個fd上面的callback函數實現的。那么，只有"活躍"的socket才會主動的去調用 callback函數，其他idle狀態socket則不會，在這點上，epoll實現了一個"偽"AIO，因為這時候推動力在os內核。在一些 benchmark中，如果所有的socket基本上都是活躍的---比如一個高速LAN環境，epoll并不比select/poll有什么效率，相反，如果過多使用epoll_ctl,效率相比還有稍微的下降。但是一旦使用idle connections模擬WAN環境,epoll的效率就遠在select/poll之上了。
    epoll_wait適用于連接數量多，但是活動連接較少的情況
  • 使用mmap加速內核與用戶空間的消息傳遞。
    這點實際上涉及到epoll的具體實現了。無論是select,poll還是epoll都需要內核把FD消息通知給用戶空間，如何避免不必要的內存拷貝就很重要，在這點上，epoll是通過內核于用戶空間mmap同一塊內存實現的。而如果你想我一樣從2.5內核就關注epoll的話，一定不會忘記手工 mmap這一步的。
  • 內核微調
    這一點其實不算epoll的優點了，而是整個linux平臺的優點。也許你可以懷疑linux平臺，但是你無法回避linux平臺賦予你微調內核的能力。比如，內核TCP/IP協議棧使用內存池管理sk_buff結構，那么可以在運行時期動態調整這個內存pool(skb_head_pool)的大小--- 通過echo XXXX>/proc/sys/net/core/hot_list_length完成。再比如listen函數的第2個參數(TCP完成3次握手的數據包隊列長度)，也可以根據你平臺內存大小動態調整。更甚至在一個數據包面數目巨大但同時每個數據包本身大小卻很小的特殊系統上嘗試最新的NAPI網卡驅動架構。

總結

  • select，poll實現需要自己不斷輪詢所有fd集合，直到設備就緒，期間可能要睡眠和喚醒多次交替。而epoll其實也需要調用epoll_wait不斷輪詢就緒鏈表，期間也可能多次睡眠和喚醒交替，但是它是設備就緒時，調用回調函數，把就緒fd放入就緒鏈表中，并喚醒在epoll_wait中進入睡眠的進程。雖然都要睡眠和交替，但是select和poll在“醒著”的時候要遍歷整個fd集合，而epoll在“醒著”的時候只要判斷一下就緒鏈表是否為空就行了，這節省了大量的CPU時間。這就是回調機制帶來的性能提升。
  • select，poll每次調用都要把fd集合從用戶態往內核態拷貝一次，并且要把current往設備等待隊列中掛一次，而epoll只要一次拷貝，而且把current往等待隊列上掛也只掛一次（在epoll_wait的開始，注意這里的等待隊列并不是設備等待隊列，只是一個epoll內部定義的等待隊列）。這也能節省不少的開銷。

參考文章

最后編輯于 ：
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明：文章內容（如有圖片或視頻亦包括在內）由作者上傳并發布，文章內容僅代表作者本人觀點，簡書系信息發布平臺，僅提供信息存儲服務。

推薦閱讀更多精彩內容