nginx學習之epoll

https://blog.csdn.net/mmshixing/article/details/51848673

首先說一下傳統的I/O多路複用select和poll，對比一下和epoll之間的區別：

舉個例子：假若有100萬用戶同時與一個進程保持TCP鏈接，而每一時刻只有幾十或者幾百個tcp鏈接是活躍的（即能接收到TCP包），那麼在每一時刻進程只須要處理這100萬鏈接中的有一小部分。

select和poll這樣處理的：在某一時刻，進程收集全部的鏈接，其實這100萬鏈接中大部分是沒有時間發生的。所以，若是每次收集事件時，都把這100萬鏈接的套接字傳給操做系統（這首先就是用戶態內存到內核內存的大量複製），而由操做系統內核尋找這些連接上沒有處理的事件，將會是巨大的浪費。

而epoll是這樣作的：epoll把select和poll分爲了兩個部分，

一、調用epoll_creat創建一個epoll對象。

二、調用epoll_ctl向epoll對象中添加這100萬個鏈接的套接字。

三、調用epoll_wait收集發生事件的鏈接。=》重點是在這裏，調用epoll_wait收集全部發生的事件的鏈接，並將事件放在一個鏈表中，這樣只需到該鏈表中尋找發生鏈接的事件，而不用遍歷100萬鏈接！這樣在實際收集事件時，epoll_wait效率會很高。

 

三個系統調用函數都是用C進行封裝，在《深刻理解Nginx》P310中由函數詳細說明，下面簡單介紹一下。

 

int epoll_create(int size);
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
int epoll_wait(int epfd, struct epoll_event *events,int maxevents, int timeout);

首先要調用epoll_create創建一個epoll對象。參數size是內核保證可以正確處理的最大句柄數，多於這個最大數時內核可不保證效果。

 

epoll_ctl能夠操做上面創建的epoll，例如，將剛創建的socket加入到epoll中讓其監控，或者把 epoll正在監控的某個socket句柄移出epoll，再也不監控它等等。

epoll_wait在調用時，在給定的timeout時間內，當在監控的全部句柄中有事件發生時，就返回用戶態的進程。

 

那麼epoll是如何實現以上想法的呢？

當某一個進程調用epoll_creat方法時，linux內核會建立一個eventpoll結構體，這個結構體中有兩個成員的使用與epoll的使用方式密切相關。

 

struct eventpoll {
    //紅黑樹的根節點，這棵樹中存儲着全部添加到epoll中的事件，也就是這個epoll監控的事件。
    struct rb_root rbr；
    //雙向鏈表rdllist保存着將要經過epoll_wait返回給用戶的、知足條件的事件。
    struct list_head rdllist；
}

 

 

epoll爲什麼如此高效：

當咱們調用epoll_ctl往裏塞入百萬個句柄時，epoll_wait仍然能夠飛快的返回，並有效的將發生事件的句柄給咱們用戶。這是因爲咱們在調用epoll_create時，內核除了幫咱們在epoll文件系統裏建了個file結點，在內核cache裏建了個紅黑樹用於存儲之後epoll_ctl傳來的socket外，還會再創建一個list鏈表，用於存儲準備就緒的事件，當epoll_wait調用時，僅僅觀察這個list鏈表裏有沒有數據便可。有數據就返回，沒有數據就sleep，等到timeout時間到後即便鏈表沒數據也返回。因此，epoll_wait很是高效。

 

並且，一般狀況下即便咱們要監控百萬計的句柄，大多一次也只返回不多量的準備就緒句柄而已，因此，epoll_wait僅須要從內核態copy少許的句柄到用戶態而已，如何能不高效？！

 

那麼，這個準備就緒list鏈表是怎麼維護的呢？當咱們執行epoll_ctl時，除了把socket放到epoll文件系統裏file對象對應的紅黑樹上以外，還會給內核中斷處理程序註冊一個回調函數，告訴內核，若是這個句柄的中斷到了，就把它放到準備就緒list鏈表裏。因此，當一個socket上有數據到了，內核在把網卡上的數據copy到內核中後就來把socket插入到準備就緒鏈表裏了。

 

如此，一顆紅黑樹，一張準備就緒句柄鏈表，少許的內核cache，就幫咱們解決了大併發下的socket處理問題。執行epoll_create時，建立了紅黑樹和就緒鏈表，執行epoll_ctl時，若是增長socket句柄，則檢查在紅黑樹中是否存在，存在當即返回，不存在則添加到樹幹上，而後向內核註冊回調函數，用於當中斷事件來臨時向準備就緒鏈表中插入數據。執行epoll_wait時馬上返回準備就緒鏈表裏的數據便可。

 

最後看看epoll獨有的兩種模式LT和ET。不管是LT和ET模式，都適用於以上所說的流程。區別是，LT模式下，只要一個句柄上的事件一次沒有處理完，會在之後調用epoll_wait時次次返回這個句柄，而ET模式僅在第一次返回。

 

這件事怎麼作到的呢？當一個socket句柄上有事件時，內核會把該句柄插入上面所說的準備就緒list鏈表，這時咱們調用epoll_wait，會把準備就緒的socket拷貝到用戶態內存，而後清空準備就緒list鏈表，最後，epoll_wait幹了件事，就是檢查這些socket，若是不是ET模式（就是LT模式的句柄了），而且這些socket上確實有未處理的事件時，又把該句柄放回到剛剛清空的準備就緒鏈表了。因此，非ET的句柄，只要它上面還有事件，epoll_wait每次都會返回。而ET模式的句柄，除非有新中斷到，即便socket上的事件沒有處理完，也是不會次次從epoll_wait返回的。

 

 

epoll的優勢：

 

1.支持一個進程打開大數目的socket描述符(FD)

    select 最不能忍受的是一個進程所打開的FD是有必定限制的，由FD_SETSIZE設置，默認值是2048。對於那些須要支持的上萬鏈接數目的IM服務器來講顯然太少了。這時候你一是能夠選擇修改這個宏而後從新編譯內核，不過資料也同時指出這樣會帶來網絡效率的降低，二是能夠選擇多進程的解決方案(傳統的 Apache方案)，不過雖然linux上面建立進程的代價比較小，但仍舊是不可忽視的，加上進程間數據同步遠比不上線程間同步的高效，因此也不是一種完美的方案。不過 epoll則沒有這個限制，它所支持的FD上限是最大能夠打開文件的數目，這個數字通常遠大於2048,舉個例子,在1GB內存的機器上大約是10萬左右，具體數目能夠cat /proc/sys/fs/file-max察看,通常來講這個數目和系統內存關係很大。

 

2.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之上了。

 

3.使用mmap加速內核與用戶空間的消息傳遞

    這點實際上涉及到epoll的具體實現了。不管是select,poll仍是epoll都須要內核把FD消息通知給用戶空間，如何避免沒必要要的內存拷貝就很重要，在這點上，epoll是經過內核於用戶空間mmap同一塊內存實現的。而若是你想我同樣從2.5內核就關注epoll的話，必定不會忘記手工 mmap這一步的。

 

4.內核微調

這一點其實不算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網卡驅動架構。