在組里饥脑，我負(fù)責(zé)一個(gè)推送通知系統(tǒng)风罩，這個(gè)系統(tǒng)主要的功能就是提醒客戶端是否該拉去最新的數(shù)據(jù)鸯檬，3周前，上線了新的功能史飞，經(jīng)過staging環(huán)境的詳細(xì)測(cè)試通過，全部部署上線后仰税，每天會(huì)受到snmp.udp.inError報(bào)警构资，這是每臺(tái)服務(wù)器內(nèi)置監(jiān)控的報(bào)警，表示udp包沒有及時(shí)處理肖卧，我們系統(tǒng)內(nèi)部都是udp通信的蚯窥。通過監(jiān)控界面查看，不是特別頻繁塞帐，丟包率不到1%拦赠，而且我們udp網(wǎng)絡(luò)庫應(yīng)用層做了重傳，不影響業(yè)務(wù)層邏輯葵姥。查看歷史記錄荷鼠，之前很少，沒這么頻繁榔幸，這個(gè)監(jiān)控理論上應(yīng)該為0允乐，從改動(dòng)上來看，功能上沒啥太大變化削咆，不應(yīng)該出現(xiàn)這個(gè)問題牍疏。
首先影響服務(wù)器的性能因素：
cpu：體現(xiàn)為多線程，多進(jìn)程充分利用多核拨齐，提高并發(fā)性能
內(nèi)存：現(xiàn)在內(nèi)存的訪問速度很快鳞陨，速度不是問題，內(nèi)存不足時(shí)瞻惋，系統(tǒng)會(huì)內(nèi)存置換厦滤，比較影響性能
網(wǎng)卡：網(wǎng)絡(luò)流量打滿了網(wǎng)卡，多余的請(qǐng)求就沒法被處理歼狼。
鎖：鎖本身并不會(huì)影響性能問題掏导，鎖的等待比較影響。
-
同步阻塞IO：如果某一個(gè)同步操作很費(fèi)事羽峰，所有的后續(xù)操作被阻塞到這個(gè)地方趟咆，所以現(xiàn)在針對(duì)IO密集型服務(wù)添瓷，異步才是最高效的方式。
該系統(tǒng)是一個(gè)io密集型的忍啸，基于有限狀態(tài)機(jī)的異步框架仰坦，同步的操作只有訪問mysql，redis這些都是異步訪問的计雌，最終需要執(zhí)行mysql的操作很少悄晃，而且mysql操作改成異步比較麻煩。所以排除鎖凿滤，先從cpu妈橄，內(nèi)存等著手處理。
查看系統(tǒng)資源監(jiān)控翁脆，cpu的idle長期處于70%眷蚓，看來cpu的利用率不足，系統(tǒng)本身是多線程的反番，線程數(shù)可配置的沙热，上調(diào)1.5倍的線程數(shù)，重啟觀察1天罢缸，發(fā)現(xiàn)沒有什么明顯的改善篙贸，還是有報(bào)警，cpu問題排除枫疆。
服務(wù)部署了2個(gè)機(jī)房爵川，我比較了下兩個(gè)機(jī)房的配置，A機(jī)房的內(nèi)存64G息楔，cpu也好寝贡，B機(jī)房32G，cpu差點(diǎn)值依，A的流量比B的少很多圃泡，首先直接系統(tǒng)是無狀態(tài)的，修改下游的路由策略愿险，改為不限定IDC洞焙，權(quán)重一致，使流量均勻拯啦，(我們內(nèi)部有一套軟件，通過分布式路由控制可以做到),上線后A機(jī)房的報(bào)警明顯減少了熔任，B機(jī)房由于流量增大褒链，之前沒有的現(xiàn)在有了部分報(bào)警。問題看上去得到緩解疑苔。
后續(xù)上線了新的功能甫匹，這次會(huì)增加和下游服務(wù)多了一次udp通信，這次上線后，報(bào)警就多了兵迅，error數(shù)有時(shí)候到了100多抢韭，這下問題就需要繼續(xù)排查了。丟包恍箭，是因?yàn)榻邮艿膗dp沒有及時(shí)處理刻恭。調(diào)低單個(gè)實(shí)例的權(quán)重，選一臺(tái)機(jī)器在上面部署兩個(gè)實(shí)例扯夭，上線觀察鳍贾，恢復(fù)回去，問題又重新出現(xiàn)交洗，通過比較發(fā)現(xiàn)骑科，問題的確是系統(tǒng)處理速度太慢」谷看看內(nèi)存占用咆爽，不到20多G，還很寬松置森，不是內(nèi)存引起的斗埂， 網(wǎng)卡流量也還不到一般，網(wǎng)卡排除暇藏。
系統(tǒng)沒什么大的變化蜜笤，難道是代碼新功能有耗時(shí)的地方，回滾了幾臺(tái)機(jī)器盐碱，觀察回滾了也沒啥效果把兔。我也是沒啥頭緒，思考再三瓮顽，先放著县好，暫時(shí)不影響業(yè)務(wù)。放置了幾天暖混。晚上下班缕贡，想起來，同步操作除了mysql訪問拣播，還有日志晾咪，我接手這個(gè)系統(tǒng)時(shí)，的確是逐漸加了一些日志贮配。線上日志的level時(shí)INFO谍倦，再調(diào)高到WARN試下，上線后觀察泪勒，error不出現(xiàn)了昼蛀⊙缁看來的確是log輸出影響了性能。問題目前來看得到了徹底的解決叼旋。但日志太少的問題仇哆，后續(xù)我們會(huì)有新的工具來實(shí)現(xiàn)分布式追蹤。
后續(xù)我又想了下夫植，這個(gè)問題一開始我的思路也是錯(cuò)了讹剔，這個(gè)系統(tǒng)本來規(guī)模就挺大，我自己首先就排除了業(yè)務(wù)增長導(dǎo)致的性能壓力偷崩，我接手了半年辟拷，半年里我司也是賣出了好幾千玩太手機(jī)，額每個(gè)手機(jī)都要連入我的服務(wù)阐斜，所以業(yè)務(wù)應(yīng)該是的確增長一些衫冻，導(dǎo)致的性能壓力。很多時(shí)候谒出，問題最后沒法解決隅俘，可能是自己把正確的解決方案先排除了。
由于半路轉(zhuǎn)的java后端笤喳，在這些問題排查方面經(jīng)驗(yàn)不足为居，特記錄一下，也算是一次經(jīng)驗(yàn)吧杀狡。
