1.描述一下伺服器配置:
一臺2c4g的centos,做api介面反代
一臺8c16g的windows 2019 作為實際伺服器,跑了iis,sql server,mongodb,redis
2.業務描述
2.0 伺服器分為兩個站點:importapi:用於處理資料匯入,,,webapi:用於處理對使用者端的資料查詢
2.1 從資料來源採集資料後,經過一系列的操作之後,寫入sql和mongodb,部分基礎資訊會快取在redis中,根據資料量的大小,從處理到寫入的整個流程時間在60ms-1200ms之間,平均每秒伺服器需要處理到2-3條資料,同一型別的資料使用佇列處理,避免併發寫入導致資料回跳或者出現髒資料的問題.
2.2 使用者web端,每秒定時透過介面讀取資料,並顯示介面上
3.使用到技術/類庫
Asp.net core 8,easycaching,freesql,redis
4.問題表現
當天晚上10點過後,突然mongodb,sqlserver和對外的webapi介面站點的程序突然cpu佔用率暴漲,mongodb平均60-80%.webapi佔用20%,sqlserver佔用10%,記憶體佔用了50%,,且遠端桌面操作不卡,webapi資料介面處理時間跟平時一樣200ms左右,但是資料不及時,透過日誌檢查的到,importapi站點原本處理時間上漲到6s-12s直接,導致了資料處理不及時,處理佇列積壓嚴重,從而導致了資料更新不及時.並且webapi介面專案不定時報"The wait queue for acquiring a connection to server 127.0.0.1:xxx is full".錯誤.從理論上說,我們的站點是小眾站點,業內人士使用,並不會出現突然湧進幾十倍的使用者的情況出現的
5.解決方式以及思路
從表現上看,是mongodb的壓力突然暴漲,導致寫入變慢,但是壓力來源是哪裡,由於還沒安裝監控皮膚,所以也沒辦法檢視,因此只能按業務反向的思路去解決,總的解決用了一下幾個點
5.1 從匯入的業務流程入手,儘量最佳化寫入以及資料分析操作所需要用的時間(之前幾天就想好的最佳化方案了,只是還沒上而已)
5.2 關掉mongodb client 的 關掉WithWriteConcern
5.3 在webapi介面專案,action上加入加上ResponseCache,過期時間3秒,(這裡的3秒主要是按業務上考慮的)
5.4 關掉反代nginx的日誌(減少點壓力,本來反代的伺服器效能就沒多高)
5.5 nginx開限流,10r/s/ip burst=20
5.6 準備一把刀(作用看後面)
以上處理後,importapi匯入的時間降低到30ms-700ms,並且webapi輸出時間降低到50-300ms(快取內50ms,快取外300ms),mongodb的cpu佔用降低到10%內,webapi佔用5%下,,
6.最終原因分析
說起來,,問題其實很簡單,本來是隻有一個前端站點把資料介面指向過來伺服器的,,前兩天遷移了另外一個站點,把資料介面也指向到這臺介面伺服器,意思就是兩個web站點,使用同一套資料介面,,新接過來的站點,前端寫完程式碼後,沒檢查,導致了一個致命的問題,由於前端使用vue,切換頁面的時候呼叫了暫停每秒一次的定時器,然後進入詳情頁後,開了一個新的定時器,也是每秒取一次另外一個介面的資料,,最大的問題就出現在,進入詳情頁後,列表頁的定時器呼叫關閉的函式報錯了,,實際定時器是沒關的,,這tm就吐血了,進去一次,開一個新的,後退到列表頁又開一個新的,,來回10次,意味著加了20個每秒請求一次的的定時器,,直接自己ddos自己.至於這個問題怎麼發現的,,,是解決完問題後,不死心,,去兩個站點裡翻找問題,本來以為這個問題在很久之前測試的時候出現過一次,應該不會再出現的,,,結果,,,,
7. 總結,,本次問題出現從晚上10點,一步一步最佳化,12點多1點的時候基本程式碼層面解決到1秒以內,,剩下的一些nginx的最佳化掃尾工作再花個不到一個鐘頭(開限流,關日誌之類的操作),順便幫前端的兩個站點的centos伺服器上,把nginx的靜態檔案gzip跟快取功能也開啟了,清理了一下寫入到mongodb的日誌,至於那把刀是今天準備給前端的