答案：采用epoll的事件模型。

首先nginx支持一下這些事件模型（參考nginx的wiki）

Nginx支持如下處理連接的方法（I/O復(fù)用方法），這些方法可以通過use指令指定。

• select?– 標(biāo)準(zhǔn)方法。 如果當(dāng)前平臺(tái)沒有更有效的方法，它是編譯時(shí)默認(rèn)的方法。你可以使用配置參數(shù)?–with-select_module?和?–without-select_module?來(lái)啟用或禁用這個(gè)模塊。
• poll?– 標(biāo)準(zhǔn)方法。 如果當(dāng)前平臺(tái)沒有更有效的方法，它是編譯時(shí)默認(rèn)的方法。你可以使用配置參數(shù)?–with-poll_module?和?–without-poll_module?來(lái)啟用或禁用這個(gè)模塊。
• kqueue?– 高效的方法，使用于 FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X. 使用雙處理器的MacOS X系統(tǒng)使用kqueue可能會(huì)造成內(nèi)核崩潰。
• epoll?– 高效的方法，使用于Linux內(nèi)核2.6版本及以后的系統(tǒng)。在某些發(fā)行版本中，如SuSE 8.2, 有讓2.4版本的內(nèi)核支持epoll的補(bǔ)丁。
• rtsig?– 可執(zhí)行的實(shí)時(shí)信號(hào)，使用于Linux內(nèi)核版本2.2.19以后的系統(tǒng)。默認(rèn)情況下整個(gè)系統(tǒng)中不能出現(xiàn)大于1024個(gè)POSIX實(shí)時(shí)(排隊(duì))信號(hào)。這種情況對(duì)于高負(fù)載的服務(wù)器來(lái)說(shuō)是低效的；所以有必要通過調(diào)節(jié)內(nèi)核參數(shù)/proc/sys/kernel/rtsig-max?來(lái)增加隊(duì)列的大小。可是從Linux內(nèi)核版本2.6.6-mm2開始， 這個(gè)參數(shù)就不再使用了，并且對(duì)于每個(gè)進(jìn)程有一個(gè)獨(dú)立的信號(hào)隊(duì)列，這個(gè)隊(duì)列的大小可以用 RLIMIT_SIGPENDING 參數(shù)調(diào)節(jié)。當(dāng)這個(gè)隊(duì)列過于擁塞，nginx就放棄它并且開始使用?poll?方法來(lái)處理連接直到恢復(fù)正常。
• /dev/poll?– 高效的方法，使用于 Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ 和 Tru64 UNIX 5.1A+.
• eventport?– 高效的方法，使用于 Solaris 10. 為了防止出現(xiàn)內(nèi)核崩潰的問題， 有必要安裝?這個(gè)?安全補(bǔ)丁。

在linux下面，只有epoll是高效的方法。

下面再來(lái)看看epoll到底是如何高效的
Epoll是Linux內(nèi)核為處理大批量句柄而作了改進(jìn)的poll。要使用epoll只需要這三個(gè)系統(tǒng)調(diào)用：epoll_create(2)， epoll_ctl(2)， epoll_wait(2)。它是在2.5.44內(nèi)核中被引進(jìn)的(epoll(4) is a new API introduced in Linux kernel 2.5.44)，在2.6內(nèi)核中得到廣泛應(yīng)用。

epoll的優(yōu)點(diǎn)

• 支持一個(gè)進(jìn)程打開大數(shù)目的socket描述符(FD)

select 最不能忍受的是一個(gè)進(jìn)程所打開的FD是有一定限制的，由FD_SETSIZE設(shè)置，默認(rèn)值是2048。對(duì)于那些需要支持的上萬(wàn)連接數(shù)目的IM服務(wù)器來(lái)說(shuō)顯然太少了。這時(shí)候你一是可以選擇修改這個(gè)宏然后重新編譯內(nèi)核，不過資料也同時(shí)指出這樣會(huì)帶來(lái)網(wǎng)絡(luò)效率的下降，二是可以選擇多進(jìn)程的解決方案(傳統(tǒng)的Apache方案)，不過雖然linux上面創(chuàng)建進(jìn)程的代價(jià)比較小，但仍舊是不可忽視的，加上進(jìn)程間數(shù)據(jù)同步遠(yuǎn)比不上線程間同步的高效，所以也不是一種完美的方案。不過 epoll則沒有這個(gè)限制，它所支持的FD上限是最大可以打開文件的數(shù)目，這個(gè)數(shù)字一般遠(yuǎn)大于2048,舉個(gè)例子,在1GB內(nèi)存的機(jī)器上大約是10萬(wàn)左右，具體數(shù)目可以cat /proc/sys/fs/file-max察看,一般來(lái)說(shuō)這個(gè)數(shù)目和系統(tǒng)內(nèi)存關(guān)系很大。

• IO效率不隨FD數(shù)目增加而線性下降

傳統(tǒng)的select/poll另一個(gè)致命弱點(diǎn)就是當(dāng)你擁有一個(gè)很大的socket集合，不過由于網(wǎng)絡(luò)延時(shí)，任一時(shí)間只有部分的socket是”活躍”的，但是select/poll每次調(diào)用都會(huì)線性掃描全部的集合，導(dǎo)致效率呈現(xiàn)線性下降。但是epoll不存在這個(gè)問題，它只會(huì)對(duì)”活躍”的socket進(jìn)行操作—這是因?yàn)樵趦?nèi)核實(shí)現(xiàn)中epoll是根據(jù)每個(gè)fd上面的callback函數(shù)實(shí)現(xiàn)的。那么，只有”活躍”的socket才會(huì)主動(dòng)的去調(diào)用 callback函數(shù)，其他idle狀態(tài)socket則不會(huì)，在這點(diǎn)上，epoll實(shí)現(xiàn)了一個(gè)”偽”AIO，因?yàn)檫@時(shí)候推動(dòng)力在os內(nèi)核。在一些 benchmark中，如果所有的socket基本上都是活躍的—比如一個(gè)高速LAN環(huán)境，epoll并不比select/poll有什么效率，相反，如果過多使用epoll_ctl,效率相比還有稍微的下降。但是一旦使用idle connections模擬WAN環(huán)境,epoll的效率就遠(yuǎn)在select/poll之上了。

• 使用mmap加速內(nèi)核與用戶空間的消息傳遞。

這點(diǎn)實(shí)際上涉及到epoll的具體實(shí)現(xiàn)了。無(wú)論是select,poll還是epoll都需要內(nèi)核把FD消息通知給用戶空間，如何避免不必要的內(nèi)存拷貝就很重要，在這點(diǎn)上，epoll是通過內(nèi)核于用戶空間mmap同一塊內(nèi)存實(shí)現(xiàn)的。而如果你想我一樣從2.5內(nèi)核就關(guān)注epoll的話，一定不會(huì)忘記手工 mmap這一步的。

• 內(nèi)核微調(diào)

這一點(diǎn)其實(shí)不算epoll的優(yōu)點(diǎn)了，而是整個(gè)linux平臺(tái)的優(yōu)點(diǎn)。也許你可以懷疑linux平臺(tái)，但是你無(wú)法回避linux平臺(tái)賦予你微調(diào)內(nèi)核的能力。比如，內(nèi)核TCP/IP協(xié)議棧使用內(nèi)存池管理sk_buff結(jié)構(gòu)，那么可以在運(yùn)行時(shí)期動(dòng)態(tài)調(diào)整這個(gè)內(nèi)存pool(skb_head_pool)的大小— 通過echo XXXX>/proc/sys/net/core/hot_list_length完成。再比如listen函數(shù)的第2個(gè)參數(shù)(TCP完成3次握手的數(shù)據(jù)包隊(duì)列長(zhǎng)度)，也可以根據(jù)你平臺(tái)內(nèi)存大小動(dòng)態(tài)調(diào)整。更甚至在一個(gè)數(shù)據(jù)包面數(shù)目巨大但同時(shí)每個(gè)數(shù)據(jù)包本身大小卻很小的特殊系統(tǒng)上嘗試最新的NAPI網(wǎng)卡驅(qū)動(dòng)架構(gòu)。

轉(zhuǎn)載于:https://blog.51cto.com/lya041/731018

總結(jié)

以上是生活随笔為你收集整理的nginx在linux为何效率高的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。