近期經(jīng)歷了一系列的nginx 50x錯誤，在此總結一下如何處理錯誤，以及各個錯誤可能根源。

錯誤處理提前需要了解

1 代碼發(fā)布時間

2 php error log

3 nginx access log

4 nginx error log

5 每個接口訪問時間log

錯誤處理流程

1. 確認是否有人剛發(fā)過代碼。根據(jù)故障時間線&代碼發(fā)布時間線，如果能找到精確對應關系，基本上可以判定這次事故的原因為代碼發(fā)布事故，回滾代碼往往是解決問題最直接有效的方式。

2. 線上測試服務器，測試接口。線上測試服務器訪問量較小，不存在nginx訪問壓力過大造成的其他隱患，可以直接測試后端的存儲服務器是否有故障。

3. 從日志挖掘有效信息。

3.1 php日志，檢查是否有大量的php報錯信息。

3.2 nginx日志，確定接口開始出現(xiàn)大量50x錯誤的時間點

3.3 接口請求時間日志（自行記錄），查看接口請求時間是否有異常。

3.4 配合xhprof等工具，分析耗時請求的時間分布。

50x原因分析：

分析前需要了解

1. php.ini

2. php-fpm.conf (訪問<?php phpinfo(); 查找"Loaded Configuration File"可以找到php-fpm.conf的位置 php -i | grep PATH | grep php; cd ../etc # 找到php-fpm.conf存儲位置)

3. nginx.conf

504:

1. 在nginx.conf keepalive_timeout時間內(nèi)php-fpm沒有返回結果

2. php-fpm設置的過少，請求過多達到php-fpm.conf pm.max_children

pm = dynamic ; The number of child processes to be created when pm is set to 'static' and the ; maximum number of child processes to be created when pm is set to 'dynamic'. ; This value sets the limit on the number of simultaneous requests that will be ; served. Equivalent to the ApacheMaxClients directive with mpm_prefork. ; Equivalent to the PHP_FCGI_CHILDREN environment variable in the original PHP ; CGI. ; Note: Used when pm is set to either 'static' or 'dynamic' ; Note: This value is mandatory. pm.max_children = 4096; The number of child processes created on startup. ; Note: Used only when pm is set to 'dynamic' ; Default Value: min_spare_servers + (max_spare_servers - min_spare_servers) / 2 pm.start_servers = 768 ; The desired minimum number of idle server processes. ; Note: Used only when pm is set to 'dynamic' ; Note: Mandatory when pm is set to 'dynamic' pm.min_spare_servers = 512

這里面我覺得最重要的參數(shù)是max_children: 代表了dynamic狀態(tài)下，fpm的最大數(shù)量。

3. nginx請求排隊超時

fpm到達上限，nginx會將fpm放入請求隊列，如果在keepalive_timeout時間內(nèi)始終沒有空閑fpm，返回504

504的access&error log

2013/08/14 20:48:31 [error] 20370#0: *1948283 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 127.0.0.1, server: lv.com.cn, request: "GET /a.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "lv.com" 127.0.0.1 - - [14/Aug/2013:20:48:31 +0800] "GET /a.php HTTP/1.1" 504 183 "-" "curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5"

502原因分析，502錯誤出現(xiàn)的原因一般都不是nginx的問題。

1. php-fpm request_terminate_timeout超時

request_terminate_timeout用于設置當某個php腳本運行最長時間，若超出php-fpm進程管理器強行中止當前程序，并關閉fastcgi和nginx的網(wǎng)絡連接，然后nginx中就會出現(xiàn)Connection reset by peer的錯誤了。

warning: php.ini中的max_execution_time在fpm中一般是不生效的，因為max_execution_time不計入網(wǎng)絡請求，系統(tǒng)請求，對于網(wǎng)絡請求，大部分都是訪問數(shù)據(jù)庫，很少有純粹的計算，因此很難超時。

盲目的延長request_terminate_timeout并不能解決問題，一般對于線上請求1s就已經(jīng)非常長了，所以如果超時，更應該去查找哪個步驟耗時，并優(yōu)化。

2. php-fpm進程出錯

想寫一個將php-fpm出現(xiàn)段錯誤，意外退出也是一件比較難的事情。大部分情況都是因為某些擴展的某些bug。(redis->pconnect遇到過, 如下)

PHP Notice:? Redis::setex(): send of 869 bytes failed with errno=32 Broken pipe in /data/home/xxx.php on line 43

3. php.ini的memory_limit過小

4. nginx.conf client head buffer，fastcgi buffer size過小

nginx錯誤日志: pstream sent too big header while reading response header from upstream

502的access&error log

2013/08/23 17:14:26 [error] 20370#0: *2529767 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 10.18.128.37, server: lv.com.cn, request: "GET /a.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "lv.com" 10.18.128.37 - - [23/Aug/2013:17:14:26 +0800] "GET /a.php HTTP/1.1" 502 575 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.57 Safari/537.17"

參考文獻
http://blog.xiuwz.com/2012/09/25/php-max-execution-time-internal/

http://www.cnblogs.com/zhengyun_ustc/archive/2013/06/06/3120967.html

轉載于:https://www.cnblogs.com/codesay/p/3278717.html

總結

以上是生活随笔為你收集整理的nginx 50x故障分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。