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的日誌,至於那把刀是今天準備給前端的