nginx-filesystem-1.0.15-12.el6.noarch |
nginx-1.0.15- 12.el6.x86_64 |
rrdtool-php-1.3.8-7.el6.x86_64 |
php-pear-1.9.4- 4.el6.noarch |
php-devel-5.3.3-46.el6_6.x86_64 |
php-mbstring-5.3.3- 46.el6_6.x86_64 |
php-mcrypt-5.3.3-3.el6.x86_64 |
#php-5.3.3-46. el6_6.x86_64 |
php-tidy-5.3.3-46.el6_6.x86_64 |
php-pecl-memcache-3.0.5- 4.el6.x86_64 |
php-xmlrpc-5.3.3-46.el6_6.x86_64 |
php-xmlseclibs-1.3.1- 3.el6.noarch |
php-common-5.3.3-46.el6_6.x86_64 |
php-pdo-5.3.3- 46.el6_6.x86_64 |
php-xml-5.3.3-46.el6_6.x86_64 |
#php-fpm-5.3.3- 46.el6_6.x86_64 |
php-cli-5.3.3-46.el6_6.x86_64 |
#php-mysql-5.3.3- 46.el6_6.x86_64 |
php-eaccelerator-0.9.6.1-1.el6.x86_64 |
php-gd-5.3.3- 46.el6_6.x86_64 |
根據nginx報的502錯誤,可以初步判斷是upstream出現了問題,再提到upstream之前,先列一下nginx的設定檔(去掉註釋,我已經將nginx記錄錯誤日誌的等級從預設等級提升到info)。
user nginx;
worker_processes 1;
error_log /var/log/nginx/error.log info;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
client_max_body_size 10M;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
keepalive_timeout 65;
include /etc/nginx/conf.d/*.conf;
}
由於此設定檔中沒有明確寫明任何server,因此需要查看include /etc/nginx/conf.d/*.conf; 所包含的預設server文件,即/etc/nginx /conf.d/default.conf,去掉註解
cat /etc/nginx/conf.d/default.conf
server {
listen 80 default_server;
server_name _;
include /etc/nginx/default.d/*.conf;
location / {
root /usr/share/nginx/html;
index index.php index.html index.htm;
}
error_page 404 /404.html;
location = /404.html {
root /usr/share/nginx/html;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
location ~ [^/]\.php(/|$) {
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
if (!-f $document_root$fastcgi_script_name) {
return 404;
}
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fastcgi_params;
}
}
初步判斷,此nginx的配置確實沒有問題,應該是php-fpm或php本身的問題(縮小問題範圍)。
查閱nginx日誌檔(/var/log/nginx/error.log),發現以下提示,確定是php-fpm的問題,fastcgi也算是對upstream的一種代理
2015/08/14 17:05:32 [notice] 9645#0: using the "epoll" event method
2015/08/14 17:05:32 [notice] 9645#0: nginx/1.0.15
2015/08/14 17:05:32 [notice] 9645#0: built by gcc 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC)
2015/08/14 17:05:32 [notice] 9645#0: OS: Linux 2.6.32-504.el6.x86_64
2015/08/14 17:05:32 [notice] 9645#0: getrlimit(RLIMIT_NOFILE): 65535:65535
2015/08/14 17:05:32 [notice] 9646#0: start worker processes
2015/08/14 17:05:32 [notice] 9646#0: start worker process 9648
2015/08/14 17:05:36 [error] 9648#0: *1 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.1.228, server: 192.168.1.101, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "192.168.1.101"
2015/08/14 17:09:22 [error] 9648#0: *4 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.1.228, server: 192.168.1.101, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "192.168.1.101"
2015/08/14 17:11:23 [error] 9648#0: *7 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.1.228, server: 192.168.1.101, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "192.168.1.101"
2015/08/14 17:11:33 [info] 9648#0: *9 client closed prematurely connection while reading client request line, client: 192.168.1.228, server: 192.168.1.101
建立一個能開啟phpinfo的文件,查看php文件能否正確解析(進一步縮小問題範圍)
發現php-fpm能正常解析php文件,裡面的各個php元件都顯示正常
查看phpMyAdmin的版本,查閱官方網站的文檔看看是否支援php5.3.3,發現目前的phpMyAdmin支持,因此應該不是phpMyAdmin的問題
開始檢查php-fpm的日誌(/var/log /php-fpm/error.log),發現如下所示:
[14-Aug-2015 16:34:53] NOTICE: fpm is running, pid 9522
[14-Aug-2015 16:34:53] NOTICE: ready to handle connections
[14-Aug-2015 16:43:54] WARNING: [pool www] child 9527 exited on signal 11 (SIGSEGV) after 541.401349 seconds from start
[14-Aug-2015 16:43:55] NOTICE: [pool www] child 9614 started
[14-Aug-2015 16:44:00] WARNING: [pool www] child 9526 exited on signal 11 (SIGSEGV) after 547.107407 seconds from start
[14-Aug-2015 16:44:00] NOTICE: [pool www] child 9615 started
[14-Aug-2015 17:05:36] WARNING: [pool www] child 9523 exited on signal 11 (SIGSEGV) after 1843.098829 seconds from start
[14-Aug-2015 17:05:36] NOTICE: [pool www] child 9649 started
這個日誌顯然不足以提供足夠的資訊來解決問題,因此修改php-fpm和php.ini對日誌等級的一些參數配置,以提升日誌級別,取得詳細的錯誤訊息。
搜尋設定檔的中log關鍵字,或根據文件或資料修改,一些方法或步驟如下:
/etc/php-fpm.conf文件,將日誌等級從notice改動到debug
log_level = debug
/etc/php-fpm.d/www.conf文件,將php worker的標準輸出和錯誤輸出從/dev/null 重定向到主要的錯誤日誌中,即/var/ log/php-fpm/error.log
catch_workers_output = yes
/etc/php.ini檔案
error_reporting = E_ALL & ~E_DEPRECATED
display_errors = On
display_startup_errors = On
log_errors = On
track_errors = On
html_errors = On
再次重新啟動php-fpm,發現worker中的詳細錯誤:
[14-Aug-2015 17:09:18] NOTICE: fpm is running, pid 9672
[14-Aug-2015 17:09:18] NOTICE: ready to handle connections
[14-Aug-2015 17:09:22] WARNING: [pool www] child 9673 said into stderr: "[Fri Aug 14 17:09:22 2015"
[14-Aug-2015 17:09:22] WARNING: [pool www] child 9673 said into stderr: "] [notice] EACCELERATOR(9673): PHP crashed on opline 30 of PMA_URL_getCommon() at /usr/share/nginx/html/libraries/url_generating.lib.php:188"
[14-Aug-2015 17:09:22] WARNING: [pool www] child 9673 said into stderr: ""
[14-Aug-2015 17:09:22] WARNING: [pool www] child 9673 exited on signal 11 (SIGSEGV) after 4.286828 seconds from start
[14-Aug-2015 17:09:22] NOTICE: [pool www] child 9679 started
[14-Aug-2015 17:11:23] WARNING: [pool www] child 9675 said into stderr: "[Fri Aug 14 17:11:23 2015"
[14-Aug-2015 17:11:23] WARNING: [pool www] child 9675 said into stderr: "] [notice] EACCELERATOR(9675): PHP crashed on opline 30 of PMA_URL_getCommon() at /usr/share/nginx/html/libraries/url_generating.lib.php:188"
錯誤訊息中提到EACCELERATOR這個php模組,因此先確定一下是不是由於這個模組有問題,因此,先將此模組停用,方法是將/etc/php.d/eaccelerator.ini檔案更改個後綴名稱,例如mv /etc/php.d/eaccelerator.ini /etc/php.d/eaccelerator.ini~,然後重新啟動php-fpm,再校驗一下結果,發現問題已經解決。
可能是eaccelerator與phpMyAdmin衝突的原因,因此要使用phpMyAdmin可以將此模組停用,或安裝時跳過這個套件。
註解:eAccelerator是一個自由開放原始碼php加速器,最佳化和動態內容緩存,提高了php腳本的快取效能,使得PHP腳本在編譯的狀態下,對伺服器的開銷幾乎完全消除。它還對腳本起優化作用,以加快其執行效率。使PHP程式碼執效率能提高1-10倍。 (來自bdbk)
問題解決想法總結
第0條,溝通是診斷故障的關鍵,詳細了解問題始末,例如部署方案,步驟,做了哪些操作等
第一,根據經驗判斷,nginx php-fpm phpMyAdmin是很牢靠的組合,因此判斷這是個例問題,而不是批量問題,因此直接開始動手,登入系統中查看安裝的軟體包,nginx、php和phpMyAdmin版本都是要查看的,此步驟有助於根據掌握的知識和經驗,初步判斷是否相互相容,是否有未修復bug等。
第二,執行nginx -t檢查nginx的設定檔有無明確錯誤,檢查nginx運行狀態
第三,執行php-fpm -t檢查php-fpm的設定文件有無顯式錯誤,檢查php-fpm的運行狀態
第四,檢查錯誤日誌,先檢查nginx的錯誤日誌,因為它是“第一現場”,再檢查php-fpm日誌,因為它是“第二現場”
第五,如果日誌提示明顯,則按照日誌提示,修改相應的配置文件,再次驗證問題
第六,如果依然有問題,則這個步驟就是解決問題的最關鍵的步驟,需要提升記錄日誌的級別,這也就是為什麼有debug為什麼叫做調試,將nginx的日誌級別提升到info(為什麼不能提升到debug,nginx編譯時有個--debug選項,不確定時可以不用),將php的日誌等級提升到debug,打開所有的php偵錯開關
第七,重新啟動nginx和php-fpm後,配置文件生效,重新開啟網頁重現問題,再次開啟日誌,根據日誌提示內容再次,修改相應的配置文件,再次驗證問題
第八,如果反復修改無果後,該查閱官方手冊就查閱官方手冊,該Google 搜索就Google搜索,該反饋bug就反饋bug,如果持續無果,則換種解決問題的方式,尋找正確的解決方案,參照如下:
最後補充一句:只要出現的問題能夠重現,而不是隨機出現,則就一定能很好的解決,因此不要慌,也不要浮躁,更不要放棄,甚至可以緩緩後再冷靜處理。
--end--