故障分析

1、登錄服務(wù)器，使用top命令看到Cpu行的iowait達(dá)到了70%以上，所以斷定是IO負(fù)載過高的原因;

2、接著使用iotop -o命令發(fā)現(xiàn),Nginx的寫IO特別大，并且在上一步的top命令看到Nginx的進(jìn)程狀態(tài)為D，表示Nginx在等待IO已經(jīng)為僵死狀態(tài);

3、這時(shí)候是清楚知道是Nginx在對文件系統(tǒng)進(jìn)行大量的寫操作導(dǎo)致的系統(tǒng)負(fù)載過高了，但還是不能知道具體Nginx在寫什么文件導(dǎo)致的負(fù)載壓力,所以我們還需要繼續(xù)追查下去;

4、我們找到其中一個(gè)nginx worker進(jìn)程的pid，使用lsof -p pid列出來的文件發(fā)現(xiàn)除了一些系統(tǒng)庫文件及日志文件，還有相當(dāng)多的fastcgi_temp/xxx文件,有可能與這些文件有關(guān)聯(lián);

5、再次使用strace -p pid追蹤,發(fā)現(xiàn)nginx進(jìn)程對某個(gè)fd進(jìn)行大量的寫操作，與lsof命令列出來的文件剛好符合;

6、使用iostat 1輸出的大量寫io的分區(qū)也與fastcgi_temp所在分區(qū)相符合;

7、猜測可能是外部正在上傳大量的大文件給php-fpm，于是通過EZHTTP的小工具來查看實(shí)時(shí)流量,發(fā)現(xiàn)入站流量其實(shí)不大，

Nginx寫IO占用高故障處理

分析結(jié)果

根據(jù)以上的故障分析，非常有可能是本機(jī)的某些程序通過http上傳大量大文件，

電腦資料

解決方案

既然清楚知道了fastcgi_temp io壓力大，目前也無法短時(shí)間從根本上解決問題，所以決定把fastcgi_temp指向/dev/shm,也就是映射到了內(nèi)存,重啟nginx之后服務(wù)恢復(fù)了正常。最終原因還需要開發(fā)配合解決。