Nginx學習：事件模塊Event基礎的核心模塊中，事件模塊是非常重要的一個部分，但是，它的配置項其實并不多，常見的或者說需要我們去配置的更少。不過本著基礎學習和了解的態(tài)度，咱們還是要一個個的學習一下。 首先來看一下什么是事件模塊。在 Nginx 中，模塊相關的配置都是在一對大花括號中的，比如 http{} 、server{} 這些，事件模塊也是類似的。 事件模塊主要是提供配置文件上下文，指定一些影響連接處理的指令，它包含 Nginx 中所有處理連接的設置。為啥事件模塊處理的是連接？ 其實，這牽涉到 Nginx 的內核運行機制，一般情況下，我們現在使用的 Linux 都支持包括 select、epoll、kqueue 這一類的 IO 模型。而這些模型現在基本都可以看成是事件機制的處理形式，只是內部略有不同。所以在命名上使用了 events ，但實際上管理的是 IO 連接。 具體的這些內容，我也只是了解個大概，比如現在最主流的就是 epoll ，它是完全的事件機制，可以實現多路 IO 復用。當一個 IO 阻塞后，讓其它的 IO 繼續(xù)處理，然后這個 IO 處理完成后觸發(fā)事件回調回來繼續(xù)處理。很像我們在日常開發(fā)中的回調函數之類的處理流程。Redis 現在主要也是依托于這種 IO 機制實現強大的處理性能。 更詳細的內容大家可以再深入的查找相關的學習資料，將來如果咱們要深入學習操作系統(tǒng)時，也可能會接觸到，到時候再說吧，現在我的水平也只能解釋到這里了。 好了，接下來我們就看看在具體的 events 模塊中，我們可以進行哪些配置。 指定 IO 模塊使用的是 use ，注意，和 user 只差一個 r 哦，而且它是寫在 events 的花括號里面的。 指定要使用的連接處理方法，可用指定為 select、poll、kqueue、epoll 等等，注意，不同的操作系統(tǒng)使用的也不一樣?，F在 Linux 下，基本都是 epoll ，FreeBSD 之類的會使用 kqueue ，其它的還有 eventport 等在一些我們不太常見的操作系統(tǒng)上可以配置。這個選項通常不需要顯式指定，因為 Nginx 會默認使用當前系統(tǒng)中最有效的模式。 換句話說，如果像我一樣，對 IO 模型不太了解的，別設置這玩意了，讓他走默認的就好。 這個命令是將 aio 與 epoll 連接處理方法一起使用時，設置單個工作進程未完成的異步 IO 操作的最大數量。這個配置指令出現在版本1.1.4和1.0.7中。現在有沒有用我也不清楚，反正直接配置是不會報錯的。使用上也沒見到有什么異常。 連接數上回我們講過一個 worker_rlimit_nofile ，它是 Nginx 整體的連接數，和系統(tǒng)的 ulimit 有點關系，或者說直接就是可以替換 ulimit 的功能，不過僅限于在 Nginx 環(huán)境中哈。今天再來學習的是事件模塊中設置工作進程可以打開的最大連接數。 它設置的是工作進程可以打開的最大同時連接數。這個數字包括所有連接（例如與代理服務器的連接等），而不僅僅是與客戶端的連接。另一個考慮因素是，同時連接的實際數量不能超過當前打開文件的最大數量限制，也就是說，它不應該超過 worker_rlimit_nofile 設置的數量。如果 Nginx 配置文件中沒有配置的話，要看下操作系統(tǒng)的 ulimit 大小。 另外，我們通過 worker_connections 和上篇文章中學習過的 worker_processes 可以計算出 maxclients （最大連接數）： 如果作為反向代理，max_clients為（除4并不一定準，是個經驗值）： worker_processes 是工作進程數，worker_connections 是工作連接數。假如設置當前 CPU 是 4 核，worker_processes 設置為 4 ；worker_connections 也設置到 10000，那么總體的最大連接數就是 4 * 10000= 40000 。 默認情況下，worker_connections 都是 512 或 1024 ，這個數字并不是說越多越好，而是要根據服務器的實際情況進行確定，一個是內存，一個是 ulimit 數量。ulimit 數量一般我們在服務器上會放到最大，因此主要就是內存。通常一個連接對應一讀一寫兩個事件，兩個事件大概占用 96 字節(jié)，連接內部大概占用 232 字節(jié)，總共 328 字節(jié)，100000 連接大概占用 31M = 100000 * 328 / 1024 / 1024 。不過具體的還是要根據實際情況來確定，因為上面的計算只是 Nginx 啟動時沒有其它任務處理的最簡單的連接占用的內存。而且處理的連接越多，CPU 負荷也越大。不過大家可以參考一些面板工具設置的默認值是多少，比如寶塔設置的 worker_rlimit_nofile 和 worker_connections 都是 51200 。 以上配置說明為網上找的以及結合一些自己的理解，有實際經驗或者研究過這一塊的大佬可以留言哈，說實話，我也沒怎么配過這個東西，但是，如果 worker_connections 給少了，會明顯地出現一個報錯，那就是 Too many open files 這個問題。一旦看到這個錯誤，就應該檢查 ulimit、worker_rlimit_nofile、worker_connections 這些配置的情況，看是不是給得太少了。 其它在事件模塊中，還有一些平常見得不多的配置，咱們最后一起來了解下。 互斥鎖相關accept_mutex 是 Nginx 中不同連接之間是否使用互斥鎖進行順序 accept() 系統(tǒng)調用的配置。如果設置為 on ，則工作進程將依次接受新連接。否則，所有工作進程都會收到有關新連接的通知，如果新連接的數量較低，則一些工作進程可能會浪費系統(tǒng)資源。 在支持 EPOLLEXCLUSIVE 標志（1.11.3）的系統(tǒng)上或使用 reuseport （HTTP模塊中的配置）時，無需啟用 accept_mutex 。在版本1.11.3之前，默認值為 on ，現在默認是 off 了。 這個配置最主要的作用是可以用來解決常說的“驚群”問題。大致意思是在某一個時刻，客戶端發(fā)來一個請求連接，Nginx后臺是以多進程的工作模式，也就是說有多個 worker 進程會被同時喚醒，但是最終只會有一個進程可以獲取到連接，如果每次喚醒的進程數目太多，就會影響 Nginx 的整體性能。如果設置為 on ，將會對多個 Nginx 進程接收連接進行序列化，一個個來喚醒接收，就防止了多個進程對連接的爭搶。 默認值是 500ms ，和 accept_mutex 相關。如果啟用了 accept_mutex ，可以指定某個工作進程檢測到其它工作進程正在接入新連接時，自身等待直到重新開始嘗試接入新連接的最大時間間隔。 debug_connection開啟針對特定客戶端連接的調試日志。除開這些連接，其它連接將使用 error_log 指令設置的日志級別。 被調試的連接可以使用 IPv4 或 IPv6 (1.3.0, 1.2.1) 網絡地址來指定， 也可以使用主機名來設置連接。 對于UNIX域套接字 (1.3.0, 1.2.1)，使用 “unix:” 參數來啟用調試日志。 干嘛用得？不知道，有用過的同學記得留言，我們一起學習哈。 multi_accept如果禁用 multi_accept ，工作進程將一次接受一個新連接。否則，工作進程將一次接受所有新連接。如果使用 kqueue 連接處理方式，則忽略該指令，因為 kqueue 可以報告有多少新連接等待接入。 在很多面板應用中，這個配置會打開。 總結學了一圈，其實我們會發(fā)現一個問題，那就是 events 中的內容其實大部分不太需要我們去配置。正常編譯安裝之后的 events 是這樣的。 而 寶塔面板 在一臺 CentOS 的服務器默認安裝完之后是這樣的。 就像上面各個配置中說到的，use 其實可以不用配，然后比較重要的就是 worker_connections ，如果是我自己配的話，直接就上 65535 了，另外 multi_accept 可以打開。更具體的配置，大家還是要根據業(yè)務情況，或者請教對這一塊有更深入研究的運維大佬們，同樣的，有心得的小伙伴記得留言，咱們大家一起學習進步哦！ 參考文檔： http:///en/docs/ngx_core_module.html http:///en/docs/events.html |
|
|
