Linux-epoll

epoll是Linux內核爲處理大批量文件描述符而作了改進的poll，是Linux下多路複用IO接口select/poll的增強版本，它能顯著提高程序在大量併發連接中只有少量活躍的情況下的系統CPU利用率。另一點原因就是獲取事件的時候，它無須遍歷整個被偵聽的描述符集，只要遍歷那些被內核IO事件異步喚醒而加入Ready隊列的描述符集合就行了。epoll除了提供select/poll那種IO事件的水平觸發（Level Triggered）外，還提供了邊緣觸發（Edge Triggered），這就使得用戶空間程序有可能緩存IO狀態，減少epoll_wait/epoll_pwait的調用，提高應用程序效率。

原文：http://blog.csdn.net/xiajun07061225/article/details/9250579

什麼是epoll

epoll是什麼？按照man手冊的說法：是爲處理大批量句柄而作了改進的poll。當然，這不是2.6內核纔有的，它是在2.5.44內核中被引進的(epoll(4) is a new API introduced in Linux kernel 2.5.44)，它幾乎具備了之前所說的一切優點，被公認爲Linux2.6下性能最好的多路I/O就緒通知方法。

 

epoll的相關係統調用

epoll只有epoll_create,epoll_ctl,epoll_wait 3個系統調用。

 

1. int epoll_create(int size);

創建一個epoll的句柄。自從linux2.6.8之後，size參數是被忽略的。需要注意的是，當創建好epoll句柄後，它就是會佔用一個fd值，在linux下如果查看/proc/進程id/fd/，是能夠看到這個fd的，所以在使用完epoll後，必須調用close()關閉，否則可能導致fd被耗盡。

 

2. int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

epoll的事件註冊函數，它不同於select()是在監聽事件時告訴內核要監聽什麼類型的事件，而是在這裏先註冊要監聽的事件類型。

第一個參數是epoll_create()的返回值。

第二個參數表示動作，用三個宏來表示：

EPOLL_CTL_ADD：註冊新的fd到epfd中；

EPOLL_CTL_MOD：修改已經註冊的fd的監聽事件；

EPOLL_CTL_DEL：從epfd中刪除一個fd；

 

第三個參數是需要監聽的fd。

第四個參數是告訴內核需要監聽什麼事，struct epoll_event結構如下：

//保存觸發事件的某個文件描述符相關的數據（與具體使用方式有關）

typedef union epoll_data {
    void *ptr;
    int fd;
    __uint32_t u32;
    __uint64_t u64;
} epoll_data_t;
 //感興趣的事件和被觸發的事件
struct epoll_event {
    __uint32_t events; /* Epoll events */
    epoll_data_t data; /* User data variable */
};

events可以是以下幾個宏的集合：

EPOLLIN ：表示對應的文件描述符可以讀（包括對端SOCKET正常關閉）；

EPOLLOUT：表示對應的文件描述符可以寫；

EPOLLPRI：表示對應的文件描述符有緊急的數據可讀（這裏應該表示有帶外數據到來）；

EPOLLERR：表示對應的文件描述符發生錯誤；

EPOLLHUP：表示對應的文件描述符被掛斷；

EPOLLET： 將EPOLL設爲邊緣觸發(Edge Triggered)模式，這是相對於水平觸發(Level Triggered)來說的。

EPOLLONESHOT：只監聽一次事件，當監聽完這次事件之後，如果還需要繼續監聽這個socket的話，需要再次把這個socket加入到EPOLL隊列裏

3. int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

收集在epoll監控的事件中已經發送的事件。參數events是分配好的epoll_event結構體數組，epoll將會把發生的事件賦值到events數組中（events不可以是空指針，內核只負責把數據複製到這個events數組中，不會去幫助我們在用戶態中分配內存）。maxevents告之內核這個events有多大，這個 maxevents的值不能大於創建epoll_create()時的size，參數timeout是超時時間（毫秒，0會立即返回，-1將不確定，也有說法說是永久阻塞）。如果函數調用成功，返回對應I/O上已準備好的文件描述符數目，如返回0表示已超時。

 

epoll工作原理

epoll同樣只告知那些就緒的文件描述符，而且當我們調用epoll_wait()獲得就緒文件描述符時，返回的不是實際的描述符，而是一個代表就緒描述符數量的值，你只需要去epoll指定的一個數組中依次取得相應數量的文件描述符即可，這裏也使用了內存映射（mmap）技術，這樣便徹底省掉了這些文件描述符在系統調用時複製的開銷。

 

另一個本質的改進在於epoll採用基於事件的就緒通知方式。在select/poll中，進程只有在調用一定的方法後，內核纔對所有監視的文件描述符進行掃描，而epoll事先通過epoll_ctl()來註冊一個文件描述符，一旦基於某個文件描述符就緒時，內核會採用類似callback的回調機制，迅速激活這個文件描述符，當進程調用epoll_wait()時便得到通知。

 

Epoll的2種工作方式-水平觸發（LT）和邊緣觸發（ET）

假如有這樣一個例子：

1. 我們已經把一個用來從管道中讀取數據的文件句柄(RFD)添加到epoll描述符

2. 這個時候從管道的另一端被寫入了2KB的數據

3. 調用epoll_wait(2)，並且它會返回RFD，說明它已經準備好讀取操作

4. 然後我們讀取了1KB的數據

5. 調用epoll_wait(2)......

Edge Triggered 工作模式：

如果我們在第1步將RFD添加到epoll描述符的時候使用了EPOLLET標誌，那麼在第5步調用epoll_wait(2)之後將有可能會掛起，因爲剩餘的數據還存在於文件的輸入緩衝區內，而且數據發出端還在等待一個針對已經發出數據的反饋信息。只有在監視的文件句柄上發生了某個事件的時候 ET 工作模式纔會彙報事件。因此在第5步的時候，調用者可能會放棄等待仍在存在於文件輸入緩衝區內的剩餘數據。在上面的例子中，會有一個事件產生在RFD句柄上，因爲在第2步執行了一個寫操作，然後，事件將會在第3步被銷燬。因爲第4步的讀取操作沒有讀空文件輸入緩衝區內的數據，因此我們在第5步調用 epoll_wait(2)完成後，是否掛起是不確定的。epoll工作在ET模式的時候，必須使用非阻塞套接口，以避免由於一個文件句柄的阻塞讀/阻塞寫操作把處理多個文件描述符的任務餓死。最好以下面的方式調用ET模式的epoll接口，在後面會介紹避免可能的缺陷。

   i    基於非阻塞文件句柄

   ii   只有當read(2)或者write(2)返回EAGAIN時才需要掛起，等待。但這並不是說每次read()時都需要循環讀，直到讀到產生一個EAGAIN才認爲此次事件處理完成，當read()返回的讀到的數據長度小於請求的數據長度時，就可以確定此時緩衝中已沒有數據了，也就可以認爲此事讀事件已處理完成。

Level Triggered 工作模式

相反的，以LT方式調用epoll接口的時候，它就相當於一個速度比較快的poll(2)，並且無論後面的數據是否被使用，因此他們具有同樣的職能。因爲即使使用ET模式的epoll，在收到多個chunk的數據的時候仍然會產生多個事件。調用者可以設定EPOLLONESHOT標誌，在 epoll_wait(2)收到事件後epoll會與事件關聯的文件句柄從epoll描述符中禁止掉。因此當EPOLLONESHOT設定後，使用帶有 EPOLL_CTL_MOD標誌的epoll_ctl(2)處理文件句柄就成爲調用者必須作的事情。

LT(level triggered)是epoll缺省的工作方式，並且同時支持block和no-block socket.在這種做法中，內核告訴你一個文件描述符是否就緒了，然後你可以對這個就緒的fd進行IO操作。如果你不作任何操作，內核還是會繼續通知你 的，所以，這種模式編程出錯誤可能性要小一點。傳統的select/poll都是這種模型的代表．

 

ET (edge-triggered)是高速工作方式，只支持no-block socket，它效率要比LT更高。ET與LT的區別在於，當一個新的事件到來時，ET模式下當然可以從epoll_wait調用中獲取到這個事件，可是如果這次沒有把這個事件對應的套接字緩衝區處理完，在這個套接字中沒有新的事件再次到來時，在ET模式下是無法再次從epoll_wait調用中獲取這個事件的。而LT模式正好相反，只要一個事件對應的套接字緩衝區還有數據，就總能從epoll_wait中獲取這個事件。

因此，LT模式下開發基於epoll的應用要簡單些，不太容易出錯。而在ET模式下事件發生時，如果沒有徹底地將緩衝區數據處理完，則會導致緩衝區中的用戶請求得不到響應。

圖示說明：

Nginx默認採用ET模式來使用epoll。

 

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網卡驅動架構。

 

linux下epoll如何實現高效處理百萬句柄的

開發高性能網絡程序時，windows開發者們言必稱iocp，linux開發者們則言必稱epoll。大家都明白epoll是一種IO多路複用技術，可以非常高效的處理數以百萬計的socket句柄，比起以前的select和poll效率高大發了。我們用起epoll來都感覺挺爽，確實快，那麼，它到底爲什麼可以高速處理這麼多併發連接呢？

 

使用起來很清晰，首先要調用epoll_create建立一個epoll對象。參數size是內核保證能夠正確處理的最大句柄數，多於這個最大數時內核可不保證效果。

 

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

 

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

 

從上面的調用方式就可以看到epoll比select/poll的優越之處：因爲後者每次調用時都要傳遞你所要監控的所有socket給select/poll系統調用，這意味着需要將用戶態的socket列表copy到內核態，如果以萬計的句柄會導致每次都要copy幾十幾百KB的內存到內核態，非常低效。而我們調用epoll_wait時就相當於以往調用select/poll，但是這時卻不用傳遞socket句柄給內核，因爲內核已經在epoll_ctl中拿到了要監控的句柄列表。

 

所以，實際上在你調用epoll_create後，內核就已經在內核態開始準備幫你存儲要監控的句柄了，每次調用epoll_ctl只是在往內核的數據結構裏塞入新的socket句柄。

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