客戶端連線過來後,多個空閒的程序,會競爭這個連線,很容易看到,這種競爭會導致不公平,如果某個程序得到 accept 的機會比較多,它的空閒連線很快就用完了,如果不提前做一些控制,當 accept 到乙個新的 tcp 連線後,因為無法得到空閒連線,而且無法將此連線轉交給其它程序,最終會導致此 tcp 連線得不到處理,就中止掉了。很顯然,這是不公平的,有的程序有空餘連線,卻沒有處理機會,有的程序因為沒有空餘連線,卻人為地丟棄連線。那麼,如何解決這個問題呢?首先,nginx 的處理得先開啟 accept_mutex 選項,此時,只有獲得了 accept_mutex 的程序才會去新增accept事件,也就是說,nginx會控制程序是否新增 accept 事件。nginx 使用乙個叫 ngx_accept_disabled 的變數來控制是否去競爭 accept_mutex 鎖。在第一段**中,計算 ngx_accept_disabled 的值,這個值是 nginx 單程序的所有連線總數的八分之一,減去剩下的空閒連線數量,得到的這個 ngx_accept_disabled 有乙個規律,當剩餘連線數小於總連線數的八分之一時,其值才大於 0,而且剩餘的連線數越小,這個值越大。再看第二段**,當 ngx_accept_disabled 大於 0 時,不會去嘗試獲取 accept_mutex 鎖,並且將 ngx_accept_disabled 減 1,於是,每次執行到此處時,都會去減 1,直到小於 0。不去獲取 accept_mutex 鎖,就是等於讓出獲取連線的機會,很顯然可以看出,當空餘連線越少時,ngx_accept_disable 越大,於是讓出的機會就越多,這樣其它程序獲取鎖的機會也就越大。不去 accept,自己的連線就控制下來了,其它程序的連線池就會得到利用,這樣,nginx 就控制了多程序間連線的平衡了。
白話說就是,nginx 會設定乙個 單個程序的可連線總數的 八分之一 作為切換連線的標準, 當這個標準 減去 單個程序的剩餘連線數 大於0 時,即所剩的連線數已經小於 總連線數的八分之一時,會讓該程序讓出 連線機會,即在該程序連線數所剩不多時,切換連線程序。
上**
ngx_accept_disabled = ngx_cycle->connection_n / 8- ngx_cycle->free_connection_n;
if (ngx_accept_disabled > 0
) else
if(ngx_accept_mutex_held)
else
}}
Nginx原始碼分析 程序管理之worker程序
本文著手分析一下worker程序的情況。首先找到worker程序的入口地方 ngx worker process cycle。這個函式不光是worker程序的入口函式,同時也是worker程序迴圈工作的主體函式,看函式名含有乙個cycle嘛。進入這個cycle函式,第一件事就是呼叫ngx worke...
C 記憶體是如何分配的
c 程式在執行時,將記憶體劃分為4個區域 1 區 存放函式體的二進位制 由作業系統進行管理的。存放cpu執行的機器指令,區是共享的,共享的目的是對於頻繁被執行的程式,只需要在記憶體中有乙份 就行了。區是唯讀的,使其唯讀的原因是防止程式意外修改了它的指令。2 全域性區 存放全域性變數和靜態變數以及常量...
C C 程式是如何分配記憶體的?
一 乙個c c 編譯的程式所占用的記憶體分為以下5部分 名稱英文 存放變數型別 分配方式 核心特點 棧區stack 函式的引數值,區域性變數等 程式執行時由編譯器自動分配,程式結束時由編譯器自動釋放。操作方式類似於資料結構中的棧 棧記憶體分配運算內置於處理器的指令集中,效率很高,但是分配的記憶體容量...