在ASP.NET Core應(yīng)用中，如果遇到"服務(wù)器爆滿"的問題，通常是指服務(wù)器無法處理更多的請求，可能是因為資源限制、并發(fā)連接數(shù)太多或者服務(wù)器配置不當(dāng)。以下是一些解決這一問題的步驟：

檢查服務(wù)器資源：確保服務(wù)器有足夠的CPU、內(nèi)存和帶寬資源來處理請求。如果資源不足，需要升級服務(wù)器硬件或優(yōu)化應(yīng)用資源使用。

調(diào)整Kestrel配置：如果使用Kestrel作為服務(wù)器，可以在Program.cs或Startup.cs中配置最大并發(fā)連接數(shù)。

1.描述一下服務(wù)器配置:

一臺2c4g的centos,做api接口反代

一臺8c16g的windows 2019 作為實際服務(wù)器,跑了iis,sql server,mongodb,redis

2.業(yè)務(wù)描述

    2.0  服務(wù)器分為兩個站點:importapi:用于處理數(shù)據(jù)導(dǎo)入,,,webapi:用于處理對用戶端的數(shù)據(jù)查詢

    2.1 從數(shù)據(jù)源采集數(shù)據(jù)后,經(jīng)過一系列的操作之后,寫入sql和mongodb,部分基礎(chǔ)信息會緩存在redis中,根據(jù)數(shù)據(jù)量的大小,從處理到寫入的整個流程時間在60ms-1200ms之間,平均每秒服務(wù)器需要處理到2-3條數(shù)據(jù),同一類型的數(shù)據(jù)使用隊列處理,避免并發(fā)寫入導(dǎo)致數(shù)據(jù)回跳或者出現(xiàn)臟數(shù)據(jù)的問題.

    2.2 用戶web端,每秒定時通過接口讀取數(shù)據(jù),并顯示界面上

3.使用到技術(shù)/類庫

    Asp.net core 8,easycaching,freesql,redis

4.問題表現(xiàn)

    當(dāng)天晚上10點過后,突然mongodb,sqlserver和對外的webapi接口站點的進(jìn)程突然cpu占用率暴漲,mongodb平均60-80%.webapi占用20%,sqlserver占用10%,內(nèi)存占用了50%,,且遠(yuǎn)程桌面操作不卡,webapi數(shù)據(jù)接口處理時間跟平時一樣200ms左右,但是數(shù)據(jù)不及時,通過日志檢查的到,importapi站點原本處理時間上漲到6s-12s直接,導(dǎo)致了數(shù)據(jù)處理不及時,處理隊列積壓嚴(yán)重,從而導(dǎo)致了數(shù)據(jù)更新不及時.并且webapi接口項目不定時報"The wait queue for acquiring a connection to server 127.0.0.1:xxx is full".錯誤.從理論上說,我們的站點是小眾站點,業(yè)內(nèi)人士使用,并不會出現(xiàn)突然涌進(jìn)幾十倍的用戶的情況出現(xiàn)的

5.解決方式以及思路

    從表現(xiàn)上看,是mongodb的壓力突然暴漲,導(dǎo)致寫入變慢,但是壓力來源是哪里,由于還沒安裝監(jiān)控面板,所以也沒辦法查看,因此只能按業(yè)務(wù)反向的思路去解決,總的解決用了一下幾個點

   5.1 從導(dǎo)入的業(yè)務(wù)流程入手,盡量優(yōu)化寫入以及數(shù)據(jù)分析操作所需要用的時間(之前幾天就想好的優(yōu)化方案了,只是還沒上而已)

   5.2 關(guān)掉mongodb client 的 關(guān)掉WithWriteConcern

   5.3 在webapi接口項目,action上加入加上ResponseCache,過期時間3秒,(這里的3秒主要是按業(yè)務(wù)上考慮的)

   5.4 關(guān)掉反代nginx的日志(減少點壓力,本來反代的服務(wù)器性能就沒多高)

   5.5  nginx開限流,10r/s/ip burst=20

   5.6 準(zhǔn)備一把刀(作用看后面)

   以上處理后,importapi導(dǎo)入的時間降低到30ms-700ms,并且webapi輸出時間降低到50-300ms(緩存內(nèi)50ms,緩存外300ms),mongodb的cpu占用降低到10%內(nèi),webapi占用5%下,,

6.最終原因分析

    說起來,,問題其實很簡單,本來是只有一個前端站點把數(shù)據(jù)接口指向過來服務(wù)器的,,前兩天遷移了另外一個站點,把數(shù)據(jù)接口也指向到這臺接口服務(wù)器,意思就是兩個web站點,使用同一套數(shù)據(jù)接口,,新接過來的站點,前端寫完代碼后,沒檢查,導(dǎo)致了一個致命的問題,由于前端使用vue,切換頁面的時候調(diào)用了暫停每秒一次的定時器,然后進(jìn)入詳情頁后,開了一個新的定時器,也是每秒取一次另外一個接口的數(shù)據(jù),,最大的問題就出現(xiàn)在,進(jìn)入詳情頁后,列表頁的定時器調(diào)用關(guān)閉的函數(shù)報錯了,,實際定時器是沒關(guān)的,,這tm就吐血了,進(jìn)去一次,開一個新的,后退到列表頁又開一個新的,,來回10次,意味著加了20個每秒請求一次的的定時器,,直接自己ddos自己.至于這個問題怎么發(fā)現(xiàn)的,,,是解決完問題后,不死心,,去兩個站點里翻找問題,本來以為這個問題在很久之前測試的時候出現(xiàn)過一次,應(yīng)該不會再出現(xiàn)的,,,結(jié)果,,,,

7. 總結(jié)

本次問題出現(xiàn)從晚上10點,一步一步優(yōu)化,12點多1點的時候基本代碼層面解決到1秒以內(nèi),剩下的一些nginx的優(yōu)化掃尾工作再花個不到一個鐘頭(開限流,關(guān)日志之類的操作),順便幫前端的兩個站點的centos服務(wù)器上,把nginx的靜態(tài)文件gzip跟緩存功能也打開了,清理了一下寫入到mongodb的日志,至于那把刀是今天準(zhǔn)備給前端的

到此這篇關(guān)于asp.net 8 服務(wù)器爆滿的解決過程的文章就介紹到這了,更多相關(guān)解決服務(wù)器爆滿內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論