項目上線一年,一個數據表使用下面這個sql,查詢10分鐘,46億多條數據,是不是很驚異,想不到吧,我當時看到這個數字,我覺得絕對是程序BUG了,然而事實是就是這麼多,言歸正傳
select id from table_name
在11月剛開始的幾天,客戶那邊突然反映了一個問題,系統訪問時快時慢的,麻煩我們給看一下找出原因並解決掉,期初以爲是後臺服務運行應用的uwsgi日誌太龐大,當晚將日誌分割了出來,這裏有個注意點,Linux系統的文件是不可以直接刪除的,因爲Linux文件系統有個信號標的問題,這裏不多敘述,需要知道的朋友自行百度一下.
清空日誌指令:
echo ""> uwsgi.log
最好是項目上線前就Nginx和uwsgi的日誌分割腳本都寫好免得尷尬
第二天下午,客戶反映沒有解決問題;好了這下就頭大了,從頭開始排查,這裏總結了一套關於這個問題的一個排查方案:
1:因爲項目是前端分離的系統,首先確認是前端還是後臺的問題,從這個地方可以看出來
Request sent(請求發送):這個有值說明你前端請求了,我這裏前端請求花費了90微秒
Waiting(TTFB)後臺響應時間:前端請求後臺共計花費了207毫秒,這個地方如果時間很長,那就可以確認是後臺的問題
2.請求到後臺Nginx路由分發,首先查看Nginx日誌,看看是否有報錯,如果沒有報錯就繼續接下來查看;
3.路由分發後再到uWSGI應用中進行請求處理,uWSGI日誌沒有報錯;
4.確認是否是硬件問題,CPU,硬盤,內存;
5.查看CPU使用率的問題,如果CPU佔用率長時間達到90以上,根據這個看看什麼進程佔用的,看看是不是有什麼接口程序計算過於頻繁,如果是CPU使用率的問題,基本可以確認是接口的問題,彙總一下每個接口的請求頻率,到這裏我想各位應該就能找出問題了吧