故障分析
1、登錄服務器，使用top命令看到Cpu行的iowait達到了70%以上，所以斷定是IO負載過高的原因;
2、接著使用iotop -o命令發現,Nginx的寫IO特別大，并且在上一步的top命令看到Nginx的進程狀態為D，表示Nginx在等待IO已經為僵死狀態;
3、這時候是清楚知道是Nginx在對文件系統進行大量的寫操作導致的系統負載過高了，但還是不能知道具體Nginx在寫什么文件導致的負載壓力,所以我們還需要繼續追查下去;
4、我們找到其中一個nginx worker進程的pid，使用lsof -p pid列出來的文件發現除了一些系統庫文件及日志文件，還有相當多的fastcgi_temp/xxx文件,有可能與這些文件有關聯;
5、再次使用strace -p pid追蹤,發現nginx進程對某個fd進行大量的寫操作，與lsof命令列出來的文件剛好符合;
6、使用iostat 1輸出的大量寫io的分區也與fastcgi_temp所在分區相符合;
7、猜測可能是外部正在上傳大量的大文件給php-fpm，于是通過EZHTTP的小工具來查看實時流量,發現入站流量其實不大，
Nginx寫IO占用高故障處理
。
分析結果
根據以上的故障分析，非常有可能是本機的某些程序通過http上傳大量大文件，
電腦資料
《Nginx寫IO占用高故障處理》(http://www.ipr-jzsc.com)。因為對程序邏輯不熟悉，也只是猜測。為了盡快恢復服務，決定實施以下解決方案。
解決方案
既然清楚知道了fastcgi_temp io壓力大，目前也無法短時間從根本上解決問題，所以決定把fastcgi_temp指向/dev/shm,也就是映射到了內存,重啟nginx之后服務恢復了正常。最終原因還需要開發配合解決。