記錄一次服務器CPU 100%的解決過程

 昨天客戶反饋業務系統很慢，並且偶爾報錯。

查看nginx日誌：

[root@s2 nginx]# tail log/error.log

2017/03/14 12:54:46 [error] 17042#17042: *9305256418 upstream timed out (110: Connection timed out) while reading response header from upstream

 

看來是請求超時了。再查看nginx.conf配置，讀取時間已經設置得比較長了。

location ^~ /api/faqs
{
    proxy_pass http://api_faqs;
        proxy_redirect default;
    proxy_set_header   Host             $host;
    proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    proxy_connect_timeout 10;
    proxy_send_timeout 10;
    proxy_read_timeout 120;
}

 

看來問題在後面的應用服務器，這裏的接口後面是有三個.Net系統在服務，分佈在兩臺windows服務器上。

其中一臺服務器上有兩個w3wp進程負責處理該接口數據，另一臺有一個進程處理。發現前者cpu使用已經100%，後者cpu使用也高達80%.

並且對應的.Net進程內存佔用高達兩個G。

奈何dotTrace和dotMemory已通過了試用期，只能本身看了。

 

使用事件查看器查看每秒請求數 Request/Sec.(在asp.net application 4裏面)，單w3wp進程發現請求實際上每秒約200多個，這個水平是低於平時的。

看來已經受cpu影響，請求處理能力大幅降低了。

 

查看數據庫服務器，top 一下，mysql cpu 使用780%+（8核32g，至關於cpu使用也是100%了）。

看來是數據庫問題，查top sql，qps。直接用sqlyog查看進程狀態就行。

發現果真是該接口同時有幾十個鏈接，在查詢數據。

對看到的sql 作索引和查詢優化後，單條sql執行時間已是0ms。這時候數據庫的cpu壓力小了點，可是 應用服務器仍是 100%。

 

最後只能分析代碼了，由於該接口是須要一次性返回大量數據。

用redis和.Net Cache作了兩級緩存，感受是緩存沒有命中，屢次請求數據庫了。

偷摸暫停接口功能，複製一樣功能的接口，打上全流程日誌查看，發現單次請求測試接口其實正常。

問題可能在高併發上，從代碼看有幾個地方有問題，最後加鎖解決。