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

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

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

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

一臺(tái)2c4g的centos,做api接口反代

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

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

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

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

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

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

    Asp.net core 8,easycaching,freesql,redis

4.問題表現(xiàn)

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

5.解決方式以及思路

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

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

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

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

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

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

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

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

6.最終原因分析

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

7. 總結(jié)

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

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

最新評論