記一次莫名其妙的網站失去響應排查。之前網站一直是使用nginx做代理后端的apache運行php來提供服務。apache經常會不定期不定時間的出現不能服務失去響應，然后nginx出現"504 Gateway Time-out"
查看錯誤日志也看不到任何東西，以為是apache的bug(其實不是，下面會說原因）。

也許年齡大了人就不愛折騰，愿意保持原狀不動，使用監控工具，每次收到報警后都重新啟動apache勉強維持著。終于有一天我煩了，不就是處理php嗎，我不用apache總行了吧，一怒之下使用源安裝php-fpm轉移到php-fpm來運行php。安裝php并不麻煩，使用源安裝還是很順利的，唯一需要做的就是設置php worker工作進程的日志輸出php錯誤日志。

一切準備就緒后把原來的proxy_pass換成fastcgipass就可以了。
代碼如下:
upstream apachephp  {
    server m.survivalescaperooms.com:8080; #Apache1
}

....
proxy_pass  http://apachephp;
替換成成
代碼如下:
upstream php {
        server 127.0.0.1:9000;
}

...
fastcgi_pass php;
就可以把apache上跑的php遷移到php-fpm上來跑。
原以為這樣就可以高枕無憂了，遷移完成是也確實沒什么問題，但是如果你不去分析問題的根本原因在哪。問題還是會找上門來，第二天nginx又報了504的gateway timeout。這回沒apache什么事了吧，apache總算撇清了關系。

那應該還是在nginx和php-fpm身上，查看nginx的錯誤日志，可以看到
代碼如下:
[error] 6695#0: *168438 upstream timed out (110: Connection timed out) while reading response header from upstream,
...
request: "GET /kd/open.php?company=chinapost&number=PA24977020344 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "m.survivalescaperooms.com"
看到這里基本上就排除了nginx嫌疑，nginx是在等待php處理"GET /kd/open.php?company=chinapost&number=PA24977020344 HTTP/1.1"超時退出了。

馬上重啟php-fpm，問題沒有了，網站可以訪問了。

再次訪問該頁面，依然沒有響應，但同時訪問別的頁面正常，該頁面刷新幾次后，整個網站都是bad gateway timeout了。

問題就縮小到這個php腳本上了。
代碼如下:
netstat -napo |grep "php5-fpm" | wc -l

查看php工作進程已經達到了配置文件里的上限10，有種感覺就是大家都被open.php這個腳本卡住了。

這個腳本是干什么的呢？這個腳本就是采集快遞信息的，里面用到了php_curl。

PHP腳本如果執行時間超過php.ini中的配置項max_execution_time不出結果就會強制退出。

查看了php.ini中max_execution_time確實配了，值為30。

萬能google派上用場了，經過不斷google后得到下面這句話

set_time_limit()函數和配置指令max_execution_time只影響腳本本身執行的時間。任何發生在諸如使用system()的系統調用，流操作，數據庫操作等的腳本執行的最大時間不包括其中，當該腳本已運行。