背景
進(jìn)入6月后，隨著一個(gè)主要功能版本api的上線，服務(wù)端的QPS翻了一倍，平時(shí)服務(wù)器的CPU使用穩(wěn)定在30%上下，高峰期則在60%上下，但是偶爾會(huì)有單臺(tái)機(jī)器出現(xiàn)持續(xù)數(shù)分鐘突然飆到90%以上，導(dǎo)致大量api響應(yīng)緩慢超過(guò)客戶端等待時(shí)間，觸發(fā)其主動(dòng)斷開(kāi)連接產(chǎn)生大量Nginx499。
問(wèn)題分析與解決
問(wèn)題期間器資源情況
仔細(xì)查看問(wèn)題期間的zabbix監(jiān)控?cái)?shù)據(jù)，發(fā)現(xiàn)90%的CPU占用中有10%上下是sys time, 5%上下是softirq time，兩者相加可占到接近20%, interrupt和context switch數(shù)由之前的10k/s飆升至20k+/s。
定位kafka log發(fā)送代碼
首先猜測(cè)就是某個(gè)新加功能實(shí)現(xiàn)有bug，可能造成長(zhǎng)時(shí)間未執(zhí)行完成，多個(gè)類似請(qǐng)求長(zhǎng)期占用CPU而后又被切換為其他線程，反復(fù)在這些耗時(shí)請(qǐng)求中來(lái)回切換卻沒(méi)法完成任意一個(gè)請(qǐng)求，并造成后續(xù)請(qǐng)求在隊(duì)列中排隊(duì)等待，導(dǎo)致大量請(qǐng)求超時(shí)響應(yīng)。直接入手分析定位新增的某個(gè)復(fù)雜功能接口，確認(rèn)不存在死循環(huán)的可能，懷疑是接口太耗性能長(zhǎng)期占用CPU導(dǎo)致后續(xù)請(qǐng)求來(lái)不及處理最終連鎖反應(yīng)導(dǎo)致雪崩。
仔細(xì)分析其實(shí)現(xiàn)，發(fā)現(xiàn)總共會(huì)觸發(fā)30+次kafka log發(fā)送，之前一直認(rèn)為使用異步批量發(fā)送kafka log的情況下，多發(fā)幾次log應(yīng)該不會(huì)存在什么問(wèn)題，不過(guò)這里一個(gè)請(qǐng)求觸發(fā)30+次 kafka log發(fā)送確實(shí)有點(diǎn)太多了。
本著懷疑的精神決定實(shí)際驗(yàn)證一番kafka log發(fā)送耗時(shí)，結(jié)果發(fā)現(xiàn)每次kafka調(diào)用耗時(shí)居然在0.2-2ms之間波動(dòng)，這相當(dāng)于該復(fù)雜接口功能請(qǐng)求光是發(fā)送kafka消息就需要6-60ms時(shí)間，與之前認(rèn)為應(yīng)該很快的假設(shè)不符！
進(jìn)一步分析原因，發(fā)現(xiàn)原來(lái)沿用的kafka producer初始化配置有大坑，其設(shè)置了batch_size=20之前一直理解為是每20條log觸發(fā)一次實(shí)際發(fā)送，結(jié)果起始batch_size的單位是字節(jié)，其表示的是每滿20字節(jié)觸發(fā)一次實(shí)際發(fā)送==！所以實(shí)際效果是每次kafka log send都會(huì)觸發(fā)實(shí)際發(fā)送。通過(guò)修改batch_size為64k并設(shè)置linger_ms為500ms，驗(yàn)證kafka log一邊為批量發(fā)送模式后，再次測(cè)試kafka消息單次調(diào)用耗時(shí)變?yōu)榱?lt;0.1ms。
修改線上api服務(wù)kafka參數(shù)，并將復(fù)雜接口kafka send操作從30+次優(yōu)化為10+次，reload服務(wù)后，意外發(fā)現(xiàn)內(nèi)存占用居然還降了50%（2G=>1G)，但是對(duì)于日常interrupt、context switch次數(shù)未觀察到明顯下降。
修改后連續(xù)幾天未再出現(xiàn)CPU飆升偶發(fā)問(wèn)題，但是堅(jiān)持不到一周再次有機(jī)器出現(xiàn)類似問(wèn)題，優(yōu)化前平均1~2天一次，多的時(shí)候一天就有兩三次，優(yōu)化后出現(xiàn)頻率降低為一周兩三次，從這個(gè)角度來(lái)看優(yōu)化具有一定效果。
嘗試擴(kuò)容解決
由于剛上了一個(gè)大版本功能，客戶端確實(shí)新增了很多api調(diào)用，隨著新版本覆蓋用戶數(shù)逐步升高，單機(jī)負(fù)載逐步升高，于是考慮再擴(kuò)個(gè)容看能否解決問(wèn)題，在某天下午快速擴(kuò)容一臺(tái)機(jī)器后，晚上又出現(xiàn)了該問(wèn)題，該簡(jiǎn)單方案宣告失敗。
定位linux內(nèi)存水位
在前兩個(gè)方案嘗試解決問(wèn)題失敗后，開(kāi)始細(xì)究一下每5分鐘打印一次的機(jī)器top快照，仔細(xì)硬瞅之下還真發(fā)現(xiàn)點(diǎn)端倪：查看了單臺(tái)機(jī)器過(guò)去近10次CPU飆漲時(shí)段的指標(biāo)，發(fā)現(xiàn)free內(nèi)存一般在CPU飆漲前剩余不到200M，而CPU恢復(fù)正常后free內(nèi)存一般都剩余>1G，這個(gè)看上去有點(diǎn)不同尋常。進(jìn)一步按圖索驥觀察到
kswapd_low_wmark_hit_quickly取值每天增長(zhǎng)上千次，直覺(jué)上感覺(jué)是偏高的。
難道問(wèn)題是free內(nèi)存不足、回收引起的？然而zabbix監(jiān)控上顯示的可用內(nèi)存一直都是>5G，理論上不應(yīng)該存在不足才對(duì)，進(jìn)一步探究了解到了free內(nèi)存回收與內(nèi)存水位的概念。
內(nèi)存水位作用
Linux的設(shè)計(jì)思路是盡量多的使用空閑內(nèi)存，除了保留一定量的真正空閑立馬可用的內(nèi)存作為free內(nèi)存保證系統(tǒng)正常運(yùn)轉(zhuǎn)外，其他空閑內(nèi)存會(huì)盡量用于系統(tǒng)緩存(buffer+cache)，當(dāng)free內(nèi)存不足時(shí)則從buffer、cache中回收為free內(nèi)存即可，而一般我們說(shuō)linux的可用內(nèi)存都是指available內(nèi)存，其實(shí)際包括free+可回收的buffer+cache內(nèi)存，這也是zabbix監(jiān)控中可用內(nèi)存使用的指標(biāo)。
那實(shí)際應(yīng)該保留多少free內(nèi)存以及何時(shí)觸發(fā)回收f(shuō)ree內(nèi)存呢？這里就需要引入linux的內(nèi)存水位(watermark)概念了，具體可參考這篇文章--Linux內(nèi)核調(diào)整watermark_scale_factor以緩解direct reclaim。簡(jiǎn)單來(lái)說(shuō)就是linux設(shè)置了min/low/high三個(gè)內(nèi)存水位，對(duì)應(yīng)free內(nèi)存在不同水位線的行為如下：
- free > high，內(nèi)存充足，什么都不用做
- free內(nèi)存由>high下降至<low，喚醒kswapd開(kāi)始內(nèi)存回收--其他進(jìn)程依然可以正常申請(qǐng)內(nèi)存
- 若free內(nèi)存一直下降至<min, 分配新內(nèi)存的進(jìn)程會(huì)直接觸發(fā)自己同步內(nèi)存回收操作--direct claim
- kswapd終于回收f(shuō)ree內(nèi)存至>high，休眠100ms休眠100ms期間若free又下降至<low，則再次喚醒kswapd，并自增kswapd_low_wmark_hit_quickly值休眠100ms后若free變?yōu)?lt;high，kswapd需繼續(xù)回收內(nèi)存至>high，而后繼續(xù)休眠100ms，并自增kswapd_low_wmark_hit_quickly值休眠100ms后若free依然>high，kswapd將進(jìn)入長(zhǎng)期sleep等待下次被喚醒
內(nèi)存水位計(jì)算與調(diào)整
而watermark的min/low/high三者的取值具體是由兩個(gè)內(nèi)核參數(shù)min_free_kbytes和watermark_scale_factor決定的，簡(jiǎn)單來(lái)說(shuō)--參考
vm內(nèi)核參數(shù)之內(nèi)存水位min_free_kbytes和保留內(nèi)存lowmem_reserve_ratio
:
watermark[WMARK_MIN] = (min_free_kbytes/4) * zone.pages/zone.allpageswatermark[WMARK_LOW] = 5/4watermark[WMARK_MIN]watermark[WMARK_HIGH] = 3/2*watermark[WMARK_MIN]
min水位直接由min_free_kbytes決定(后面的zone.pages/zone.allpages表示不同內(nèi)存區(qū)按占總物理內(nèi)存的比例均分對(duì)應(yīng)水位值)，而后min/low/high之間的差值則=1/4low，所以在一臺(tái)8G(7969M)的線上機(jī)器上min/low/high取值默認(rèn)為：
Node 0, zone DMA per-node stats nr_inactive_anon 21704 nr_active_anon 171130 nr_inactive_file 1490263 nr_active_file 153139--Node 0, zone DMA32 pages free 58451 min 6322 low 7902 high 9482 node_scanned 0--Node 0, zone Normal pages free 13169 min 10540 low 13175 high 15810 node_scanned 0
主要的Normal區(qū)域的min/low/high差值也就105400.254KB=10M左右，如果線上有突增流量，很可能一下子就跑到low乃至min水位之下了。
內(nèi)存水位調(diào)整效果
通過(guò)watermark_scale_factor參數(shù)將默認(rèn)值10/10000調(diào)整為200/10000，內(nèi)存水位取值變?yōu)椋?/p>
Node 0, zone DMA per-node stats nr_inactive_anon 21910 nr_active_anon 278859 nr_inactive_file 1366921 nr_active_file 150022--Node 0, zone DMA32 pages free 56340 min 6342 low 21660 high 36978 node_scanned 0--Node 0, zone Normal pages free 35915 min 10520 low 35926 high 61332 node_scanned 0
Normal zone內(nèi)存水位min/low/high差值變?yōu)?low-min=99MB，調(diào)整完后對(duì)單臺(tái)機(jī)器逐步放量至近期峰值的150%流量測(cè)試，未再出現(xiàn)該問(wèn)題，至今2周過(guò)去了，線上機(jī)器未再出現(xiàn)該問(wèn)題。
另一個(gè)驗(yàn)證水位調(diào)整效果的數(shù)據(jù)是查看并自增
kswapd_low_wmark_hit_quickly值變化值，在調(diào)整水位值之前，每天kswapd_low_wmark_hit_quickly新增在1000左右，調(diào)整后變?yōu)?00次，降低了一個(gè)數(shù)量級(jí)。
