99久久99久久精品免观看,国产精品久久久久国产精品,国产黄色录像视频,免费的黄色毛片,国产一区精品普通话对白,色妞妞成人在线观看,最新aⅴ福利在线观看免费

綠色資源網(wǎng):您身邊最放心的安全下載站! 最新軟件|熱門排行|軟件分類|軟件專題|廠商大全

綠色資源網(wǎng)

技術(shù)教程
您的位置:首頁服務(wù)器類Web服務(wù)器 → nginx報的http錯誤

nginx報的http錯誤

我要評論 2012/11/29 20:49:41 來源:綠色資源網(wǎng) 編輯:www.siawh.com [ ] 評論:0 點擊:335次

Nginx 502 Bad Gateway的含義是請求的PHP-CGI已經(jīng)執(zhí)行,但是由于某種原因(一般是讀取資源的問題)沒有執(zhí)行完畢而導(dǎo)致PHP-CGI進程終止。
Nginx 504 Gateway Time-out的含義是所請求的網(wǎng)關(guān)沒有請求到,簡單來說就是沒有請求到可以執(zhí)行的PHP-CGI。

解決這兩個問題其實是需要綜合思考的,一般來說Nginx 502 Bad Gateway和php-fpm.conf的設(shè)置有關(guān),而Nginx 504 Gateway Time-out則是與nginx.conf的設(shè)置有關(guān)。

1.查看FastCGI進程是否已經(jīng)啟動
NGINX 502錯誤的含義是sock、端口沒被監(jiān)聽造成的。我們先檢查fastcgi是否在運行
2.檢查系統(tǒng)Fastcgi進程運行情況
除了第一種情況,fastcgi進程數(shù)不夠用、php執(zhí)行時間長、或者是php-cgi進程死掉也可能造成nginx的502錯誤
運行以下命令判斷是否接近FastCGI進程,如果fastcgi進程數(shù)接近配置文件中設(shè)置的數(shù)值,表明worker進程數(shù)設(shè)置太少
netstat -anpo | grep "php-cgi" | wc -l
3.FastCGI執(zhí)行時間過長
根據(jù)實際情況調(diào)高以下參數(shù)值
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;

4.頭部太大這種情況可能是由于nginx默認的fastcgi進程響應(yīng)的緩沖區(qū)太小造成的, 這將導(dǎo)致fastcgi進程被掛起, 如果你的fastcgi服務(wù)對這個掛起處理的不好, 那么最后就極有可能導(dǎo)致504 Gateway Time-out
現(xiàn)在的網(wǎng)站, 尤其某些論壇有大量的回復(fù)和很多內(nèi)容的, 一個頁面甚至有幾百K
默認的fastcgi進程響應(yīng)的緩沖區(qū)是8K, 我們可以設(shè)置大點:                               
fastcgi_buffer_size 128k;
fastcgi_buffers 8 128k;
如果你使用的是nginx的負載均衡Proxying,調(diào)整
proxy_buffer_size  16k;   這里參數(shù)調(diào)大
proxy_buffers   4 16k;
5.https轉(zhuǎn)發(fā)配置錯誤
正確的配置方法
server_name www.xok.la;
location /myproj/repos {
set $fixed_destination $http_destination;
if ( $http_destination ~* ^https(.*)$ )
{
set $fixed_destination http$1;
}
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Destination $fixed_destination;
proxy_pass http://subversion_hosts;
}

下面我們來仔細分析一下php-fpm.conf幾個重要的參數(shù):
php-fpm.conf有兩個至關(guān)重要的參數(shù),一個是”max_children”,另一個是”request_terminate_timeout”
我的兩個設(shè)置的值一個是”40″,一個是”900″,但是這個值不是通用的,而是需要自己計算的。
計算的方式如下:
如果你的服務(wù)器性能足夠好,且寬帶資源足夠充足,PHP腳本沒有系循環(huán)或BUG的話你可以直接將”request_terminate_timeout” 設(shè)置成0s。0s的含義是讓PHP-CGI一直執(zhí)行下去而沒有時間限制。而如果你做不到這一點,也就是說你的PHP-CGI可能出現(xiàn)某個BUG,或者你的寬帶不夠充足或者其他的原因?qū)е履愕腜HP-CGI能夠假死那么就建議你給”request_terminate_timeout”賦一個值,這個值可以根據(jù)你服務(wù)器的性能進行設(shè)定。一般來說性能越好你可以設(shè)置越高,20分鐘-30分鐘都可以。由于我的服務(wù)器PHP腳本需要長時間運行,有的可能會超過10 分鐘因此我設(shè)置了900秒,這樣不會導(dǎo)致PHP-CGI死掉而出現(xiàn)502 Bad gateway這個錯誤。

而”max_children”這個值又是怎么計算出來的呢?這個值原則上是越大越好,php-cgi的進程多了就會處理的很快,排隊的請求就會很少。設(shè)置”max_children”也需要根據(jù)服務(wù)器的性能進行設(shè)定,一般來說一臺服務(wù)器正常情況下每一個php-cgi所耗費的內(nèi)存在20M左右,因此我的”max_children”我設(shè)置成40個,20M*40=800M也就是說在峰值的時候所有PHP-CGI所耗內(nèi)存在800M以內(nèi),低于我的有效內(nèi)存1Gb。而如果我的”max_children”設(shè)置的較小,比如5-10個,那么php-cgi就會“很累”,處理速度也很慢,等待的時間也較長。如果長時間沒有得到處理的請求就會出現(xiàn)504 Gateway Time-out這個錯誤,而正在處理的很累的那幾個php-cgi如果遇到了問題就會出現(xiàn)502 Bad gateway這個錯誤。

一個實例:

http://www.levil.cn/post/29/
 

我在CentOS下配置lnmp組合基本上用的都是同樣的配置文件,一直都沒出現(xiàn)過問題,可最近在一個vps上安裝同樣的環(huán)境之后,網(wǎng)站在線10多人就出現(xiàn)了打開速度非常緩慢的情況,有好幾次都是直接達到了nginx中設(shè)置的腳本最大超時時間300秒,結(jié)果導(dǎo)致nginx往客戶端瀏覽器發(fā)送了一個504 Gateway Time-out的錯誤代碼,分析了之后改動了幾處配置文件,終于避免了該情況的出現(xiàn)。

從錯誤代碼基本可以確定跟nginx本身無關(guān),主要是提交給php-fpm的請求未能正確反饋而導(dǎo)致,一般情況下,提交動態(tài)請求的時候,nginx會直接把請求轉(zhuǎn)交給php-fpm,而php-fpm再分配php-cgi進程來處理相關(guān)的請求,之后再依次返回,最后由nginx把結(jié)果反饋給客戶端瀏覽器,但我這個vps目前跑的是個純php應(yīng)用內(nèi)容,實際上用戶所有的請求都是php請求,有的耗費時間比較久,php-cgi進程就一直都被用滿,而php- fpm本身的配置文件只打開了10組php-cgi進程,這樣的話在線用戶稍微多的話就會導(dǎo)致請求無法被正常處理而出錯。

大概分析出了原因,下面做就比較容易了,首先是更改php-fpm的幾處配置:

把max_children由之前的10改為現(xiàn)在的30,這樣就可以保證有充足的php-cgi進程可以被使用;
把request_terminate_timeout由之前的0s改為60s,這樣php-cgi進程處理腳本的超時時間就是60秒,可以防止進程都被掛起,提高利用效率。

接著再更改nginx的幾個配置項,減少FastCGI的請求次數(shù),盡量維持buffers不變:

fastcgi_buffers由 4 64k 改為 2 256k;
fastcgi_buffer_size由 64k 改為 128K;
fastcgi_busy_buffers_size 由 128K 改為 256K;
fastcgi_temp_file_write_size 由 128K 改為 256K。

好了,重新加載php-fpm和nginx的配置,再次測試,至今兩周時間內(nèi)沒有再出現(xiàn)504 Gateway Time-out的情況,算是達到效果了。

另一例子:

使用ie正常.其他人用FF也正常.但是有個人使用FF瀏覽報錯502
查看后臺error日志,發(fā)現(xiàn)一句
upstream sent too big header while reading response header from upstream
就是反饋回來的頭部信息太大
一般應(yīng)該是cookie里面帶的
懷疑是FF里面的某個插件引起返回太多的頭部信息
一個個排查.最后發(fā)現(xiàn)是FireBug導(dǎo)致的
既然是fastcgi返回的頭部太大.應(yīng)該可以配置
查找資料后發(fā)現(xiàn)應(yīng)該是和fastcgi_buffer_*有關(guān)的
將相關(guān)配置增大.發(fā)現(xiàn)問題解決
這邊使用的是
fastcgi_buffer_size 32k;
fastcgi_buffers 8 32k;
比原來的默認4k/8k要大許多

http400錯:
nginx的HTTP400錯誤,而且這個HTTP400錯誤并不是每次都會出現(xiàn)的,查了一下發(fā)現(xiàn)nginx 400錯誤是由于request header過大,通常是由于cookie中寫入了較長的字符串所引起的。解決方法是不要在cookie里記錄過多數(shù)據(jù),如果實在需要的話可以考慮調(diào)整在nginx.conf中的client_header_buffer_size(默認1k)
若cookie太大,可能還需要調(diào)整large_client_header_buffers(默認4k),該參數(shù)說明如下:
請求行如果超過buffer,就會報HTTP 414錯誤(URI Too Long)
nginx接受最長的HTTP頭部大小必須比其中一個buffer大,否則就會報400的HTTP錯誤(Bad Request)。
 
http413錯:
在上傳時nginx返回了413錯誤,查看log文件,顯示的錯誤信息是:”413 Request Entity Too Large”, 于是在網(wǎng)上找了下“nginx 413錯誤”發(fā)現(xiàn)需要做以下設(shè)置:
在nginx.conf增加client_max_body_size的設(shè)置, 這個值默認是1m,可以增加到8m

關(guān)鍵詞:nginx,http錯誤

閱讀本文后您有什么感想? 已有 人給出評價!

  • 0 歡迎喜歡
  • 0 白癡
  • 0 拜托
  • 0 哇
  • 0 加油
  • 0 鄙視