webman 進程busy

MarkGo 更新于2022-03-26

一個供第三方實時查詢的接口，
大概qps是30左右，
查看status時發(fā)現(xiàn)線程偶爾出現(xiàn)busy狀態(tài)，但持續(xù)不超3秒，所以用手冊中關(guān)于busy的排查方法無法定位到問題。
請問有沒有什么更加有效的手段進行排查？

CPU和內(nèi)存都在10%以下；

 2519  2 0

Tinywan 2022-03-26

正常

MarkGo 2022-03-28

原因之前看了很多帖子，其實能肯定就是非webman的問題，主要是想看看有什么手段定位具體產(chǎn)生原因，業(yè)務(wù)日志1天就幾十MB了，通過業(yè)務(wù)日志定位相對難，而且這個是偶現(xiàn)問題，即如果我用相同條件去發(fā)起請求，不一定就busy，但10次有2~3次會出現(xiàn)BUSY。就如下面回復(fù)到的，猜測是帶寬問題，但還是想確認下。

walkor 2022-03-26

打賞

短暫busy沒有問題，不用管。busy的意思是進程在處理慢業(yè)務(wù)，本身就是慢業(yè)務(wù)的不用管。

MarkGo 2022-03-28

好的謝謝，主要是想找出“慢業(yè)務(wù)”，另外就是想確認下，如果發(fā)送不及時會否導(dǎo)致產(chǎn)生busy？因?qū)嶋H上那臺服務(wù)器上跑了兩個類似這樣的服務(wù)（兩個單獨的webman），QPS合計估計50~60，但是服務(wù)器帶寬只有5M，平均每次請求返回包大小10KB，所以猜測是否因為出口帶寬打滿，導(dǎo)致出現(xiàn)進程BUSY，這個可能性會有嗎？
walkor 2022-03-28

如果是每秒60個10KB的包，帶寬基本上就滿了
nitron 2022-03-28

想找出慢業(yè)務(wù),最直接的方式是記錄每個請求的實行時間,看status沒用
MarkGo 2022-03-29

量過大，實際情況很難篩選出過慢的請求，但是這一步其實也做了，但是就如上面回復(fù)的，通過相同參數(shù)重發(fā)請求也無法100%復(fù)現(xiàn)這個問題，想到畢竟還有其他因素的存在，例如busy時數(shù)據(jù)庫是否繁忙，內(nèi)網(wǎng)是否有波動等客觀因素，但結(jié)合已有信息猜測是帶寬問題，只是無法進一步確定
nitron 2022-03-29

BaseController的beforeAction記錄起始時間,afterAction記錄結(jié)束時間,所有Controller都會自動調(diào)用