無論你是作運維仍是作開發，哪怕你是遊客，時不時會遇到502 Bad Gateway或504 Gateway Time-out。出現這頁面，把服務重啓下，再實在不行重啓下服務器，問題就解決了，可是，這問題仍是會困擾着你，特別是作運維的人員。夜黑風高正酣睡時，一個電話響起，讓你重啓服務或IISRESET，確定是極大不爽，立馬要問候他媽了。呵呵，本文總結502與504故障分析與解決方法。html
二. 狀態碼解釋前端
502 Bad Gateway：做爲網關或者代理工做的服務器嘗試執行請求時，從上游服務器接收到無效的響應。
504 Gateway Time-out：做爲網關或者代理工做的服務器嘗試執行請求時，未能及時從上游服務器（URI標識出的服務器，例如HTTP、FTP、LDAP）或者輔助服務器（例如DNS）收到響應。nginx
三. 502 Bad Gateway緣由分析
將請求提交給網關如php-fpm執行，可是因爲某些緣由沒有執行完畢致使php-fpm進程終止執行。說到此，這個問題就很明瞭了，與網關服務如php-fpm的配置有關了。
php-fpm.conf配置文件中有兩個參數就須要你考慮到，分別是max_children和request_terminate_timeout。
max_children最大子進程數，在高併發請求下，達到php-fpm最大響應數，後續的請求就會出現502錯誤的。能夠經過netstat命令來查看當前鏈接數。
request_terminate_timeout設置單個請求的超時終止時間。還應該注意到php.ini中的max_execution_time參數。當請求終止時，也會出現502錯誤的。
當積累了大量的php請求，你重啓php-fpm釋放資源，但一兩分鐘不到，502又再次呈現，這是什麼緣由致使的呢？ 這時還應該考慮到數據庫，查看下數據庫進程是否有大量的locked進程，數據庫死鎖致使超時，前端終止了繼續請求，可是SQL語句還在等待釋放鎖，這時就要重啓數據庫服務了或kill掉死鎖SQL進程了。
對於長時間的請求能夠考慮使用異步方式，能夠參閱《關於PHP實現異步操做的研究》。數據庫
四. 504 Gateway Time-out緣由分析
504錯誤通常是與nginx.conf配置有關了。主要與如下幾個參數有關：fastcgi_connect_timeout、fastcgi_send_timeout、fastcgi_read_timeout、fastcgi_buffer_size、fastcgi_buffers、fastcgi_busy_buffers_size、fastcgi_temp_file_write_size、fastcgi_intercept_errors。特別是前三個超時時間。若是fastcgi緩衝區過小會致使fastcgi進程被掛起從而演變爲504錯誤。服務器
五. 小結
總而言之，502錯誤主要從四個方向入手：
1. max_children
2. request_terminate_timeout、max_execution_time
3. 數據庫
4. 網關服務是否啓動如php-fpm併發
504錯誤主要查看nginx.conf關於網關如fastcgi的配置。運維