一次難忘的nginx性能調(diào)優(yōu)經(jīng)歷

1 32核1610單板測試結(jié)果:

紫色行為未開啟“keepalive”最佳TPS配置

藍(lán)色行為開啟“keepalive”最佳TPS配置

在保持進(jìn)程數(shù)比例proxy:server為2:1的情況下，nginx server個(gè)數(shù)增加，TPS呈現(xiàn)較好的線性提升，直到server個(gè)數(shù)超過7個(gè)，TPS趨于平穩(wěn)，達(dá)到性能瓶頸。

2 原因分析

2.1 2-10-8*1 Perf熱點(diǎn)函數(shù)抓取結(jié)果：osq_lock占比4.61%

perf record -C 20-29 –g

perf report -g --no-childr

2.2 2-16-8*1 Perf熱點(diǎn)函數(shù)抓取結(jié)果：osq_lock占比28.84%

perf record -C 14-29 –g

perf report -g --no-children

2.3 2.3 2-22-8*1 Perf熱點(diǎn)函數(shù)抓取結(jié)果：osq_lock占比38.34%

perf record -C 8-29 –g

perf report -g --no-children

2.4 “keepalive“參數(shù)含義：設(shè)置到upstream服務(wù)器的空閑keepalive連接的最大數(shù)量

keepalive參數(shù)的含義非常的奇特，請看nginx文檔中的說明:

Syntax: keepalive connections;

Default: —

Context: upstream

Activates the cache for connections to upstream servers. 激活到upstream服務(wù)器的連接緩存。 The connections parameter sets the maximum number of idle keepalive connections to upstream servers that are preserved in the cache of each worker process. When this number is exceeded, the least recently used connections are closed. connections參數(shù)設(shè)置每個(gè)worker進(jìn)程在緩沖中保持的到upstream服務(wù)器的空閑keepalive連接的最大數(shù)量.當(dāng)這個(gè)數(shù)量被突破時(shí)，最近使用最少的連接將被關(guān)閉。 It should be particularly noted that the keepalive directive does not limit the total number of connections to upstream servers that an nginx worker process can open. The connections parameter should be set to a number small enough to let upstream servers process new incoming connections as well. 特別提醒：keepalive指令不會(huì)限制一個(gè)nginx worker進(jìn)程到upstream服務(wù)器連接的總數(shù)量。connections參數(shù)應(yīng)該設(shè)置為一個(gè)足夠小的數(shù)字來讓upstream服務(wù)器來處理新進(jìn)來的連接。

2.5 設(shè)置到upstream服務(wù)器的空閑keepalive連接的最大數(shù)量為800后：2-22-8*1 Perf熱點(diǎn)函數(shù)抓取結(jié)果：osq_lock占比61.10%

upstreammysvr{

server127.0.0.1:81weight=10;

server127.0.0.1:82weight=10;

server127.0.0.1:83weight=10;

server127.0.0.1:84weight=10;

server127.0.0.1:85weight=10;

server127.0.0.1:86weight=10;

server127.0.0.1:87weight=10;

server127.0.0.1:88weight=10;

keepalive800;

}

server{

listen??????80;

location/{

proxy_passhttp://mysvr;

proxy_http_version1.1;

proxy_set_headerConnection"";

}

2.6 osq_lock熱點(diǎn)函數(shù)調(diào)用流程圖

2.7 性能瓶頸原因分析

從4組Perf抓取的熱點(diǎn)函數(shù)”osq_lock”占比數(shù)據(jù)可以看出，當(dāng)nginx proxy在進(jìn)程數(shù)超過16個(gè)后，osq-lock占比急劇上升，并且當(dāng)全部使用長連接后osq_lock的占比進(jìn)一步提升達(dá)到61%，差不多是之前的2倍，而此時(shí)的CPU使用率并不滿，才86%。

從這些結(jié)果出發(fā)，我懷疑osq_lock的占比在核數(shù)提升后急劇提高是由于長連接引起的，為了驗(yàn)證我將長連接的“keepalive”設(shè)置為0，果然osq_lock就沒有占比了，進(jìn)一步驗(yàn)證將“keepalive”設(shè)置為20，osq_lock占比為29.91%，“keepalive”設(shè)置為40以上，則osq_lock占比約為61%，此時(shí)可以確認(rèn)osq_lock占比急劇上升是由于設(shè)置長連接且核數(shù)超過16個(gè)后引起的。

為了挖掘深層原因，我查看了nginx官方文檔，源碼和linux內(nèi)核源碼，有如下發(fā)現(xiàn)。

在http1.1中，引入了一種新的特性，即pipeline。那么什么是pipeline呢？pipeline其實(shí)就是流水線作業(yè)，它可以看作為keepalive的一種升華，因?yàn)閜ipeline也是基于長連接的，目的就是利用一個(gè)連接做多次請求。如果客戶端要提交多個(gè)請求，對于keepalive來說，那么第二個(gè)請求，必須要等到第一個(gè)請求的響應(yīng)接收完全后，才能發(fā)起，這和TCP的停止等待協(xié)議是一樣的，得到兩個(gè)響應(yīng)的時(shí)間至少為2*RTT。而對pipeline來說，客戶端不必等到第一個(gè)請求處理完后，就可以馬上發(fā)起第二個(gè)請求。得到兩個(gè)響應(yīng)的時(shí)間可能能夠達(dá)到1*RTT。nginx是直接支持pipeline的，但是，nginx對pipeline中的多個(gè)請求的處理卻不是并行的，依然是一個(gè)請求接一個(gè)請求的處理，只是在處理第一個(gè)請求的時(shí)候，客戶端就可以發(fā)起第二個(gè)請求。這樣，nginx利用pipeline減少了處理完一個(gè)請求后，等待第二個(gè)請求的請求頭數(shù)據(jù)的時(shí)間。其實(shí)nginx的做法很簡單，前面說到，nginx在讀取數(shù)據(jù)時(shí)，會(huì)將讀取的數(shù)據(jù)放到一個(gè)buffer里面，所以，如果nginx在處理完前一個(gè)請求后，如果發(fā)現(xiàn)buffer里面還有數(shù)據(jù)，就認(rèn)為剩下的數(shù)據(jù)是下一個(gè)請求的開始，然后就接下來處理下一個(gè)請求，否則就設(shè)置keepalive。

如果使用長連接，就可以利用一個(gè)連接做多次請求，這些請求來自不同進(jìn)程，在請求結(jié)束時(shí)，這些進(jìn)程要寫同一個(gè)log文件。Linux為了支持多進(jìn)程訪問共享資源引入了鎖，而當(dāng)進(jìn)程數(shù)超過16個(gè)后，鎖出現(xiàn)的情況大幅上升，CPU的性能很大一部分被鎖給消耗，造成了進(jìn)程增加，性能上不去的情況，特別的看下面3種情況，當(dāng)nginx proxy的進(jìn)程從16上升到22時(shí)，吞吐量基本沒有提升，每個(gè)進(jìn)程還都滿負(fù)載，多余的CPU性能都被osq_lock給消耗了。

2.8 結(jié)論

nginx proxy在進(jìn)程數(shù)超過16后的性能瓶頸在于nginx使用長連接后多進(jìn)程同時(shí)寫log文件和Linux為了支持多進(jìn)程訪問共享資源引入了鎖（mutex_lock，spin_lock，osq_lock等）。

針對這個(gè)問題，現(xiàn)有解決辦法就是不記錄log，利用以下設(shè)置就可以突破寫log帶來的性能瓶頸：

access_log /dev/null; //將存儲(chǔ)access_log的路徑設(shè)置為“垃圾桶”

error_log /dev/null; //將存儲(chǔ)error_log的路徑設(shè)置為“垃圾桶”。

采用長連接并且不記錄log后，最優(yōu)配置“單client5核-單proxy17核-單server10核”下TPS達(dá)到了271944 req/s，且32核全部滿負(fù)荷。

轉(zhuǎn)載請注明出處：華為云博客 https://portal.hwclouds.com/blogs

Nginx 互聯(lián)網(wǎng)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。