414 Request-URI Too Large
|
1
2
3
4
5
6
|
#客戶端請求頭緩沖區(qū)大小，如果請求頭總長度大于小于128k，則使用此緩沖區(qū)，#請求頭總長度大于128k時使用large_client_header_buffers設(shè)置的緩存區(qū)client_header_buffer_size 128k;#large_client_header_buffers 指令參數(shù)4為個數(shù)，128k為大小，默認是8k。申請4個128k。large_client_header_buffers 4 128k; |
當http 的URI太長或者request header過大時會報414 Request URI too large或400 bad request錯誤。
可能原因
場景1.cookie中寫入的值太大造成的，因為header中的其他參數(shù)的size一般比較固定，只有cookie可能被寫入較大的數(shù)據(jù)
場景2.請求參數(shù)太長，比如發(fā)布一個文章正文，用urlencode后，使用get方式傳到后臺。
|
1
2
3
4
5
6
7
8
9
10
11
|
GET http://m.ythuaji.com.cn/ HTTP/1.1Host: m.ythuaji.com.cnConnection: keep-aliveCache-Control: max-age=0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.31 Accept-Encoding: gzip,deflate,sdchAccept-Language: zh-CN,zh;q=0.8Accept-Charset: GBK,utf-8;q=0.7,*;q=0.3Cookie: bdshare_firstime=1363517175366; If-Modified-Since: Mon, 13 May 2013 13:40:02 GMT |
當請求頭過大時，超過large_client_header_buffer時，
nginx可能返回"Request URI too large" (414)或者"Bad-request"(400)錯誤,
如上例HTTP請求頭由多行構(gòu)成，
其中"GET http://m.ythuaji.com.cn/ HTTP/1.1"表示Request line
當Request line的長度大于large_client_header_buffer的一個buffer(128k)時，nginx會返回"Request URI too large" (414)錯誤，對應(yīng)上面的場景2。
請求投中最長的一行也要小于large_client_header_buffer，當不是Request line的最長行大于一個buffer(128k)時，會返回"Bad-request"(400)錯誤，對應(yīng)上面的場景1。
解決辦法：這時可以調(diào)大上述兩個值。
|
1
2
|
client_header_buffer_size 512k;large_client_header_buffers 4 512k; |
504 Gateway Time-out
之前網(wǎng)站一直是使用nginx做代理后端的apache運行php來提供服務(wù)。
apache經(jīng)常會不定期不定時間的出現(xiàn)不能服務(wù)失去響應(yīng)，然后nginx出現(xiàn)"504 Gateway Time-out"
查看錯誤日志也看不到任何東西，以為是apache的bug(其實不是，下面會說原因）。
也許年齡大了人就不愛折騰，愿意保持原狀不動，使用監(jiān)控工具，每次收到報警后都重新啟動apache勉強維持著。
終于有一天我煩了，不就是處理php嗎，我不用apache總行了吧，一怒之下使用源安裝php-fpm轉(zhuǎn)移到php-fpm來運行php。
安裝php并不麻煩，使用源安裝還是很順利的，唯一需要做的就是設(shè)置php worker工作進程的日志輸出php錯誤日志。
一切準備就緒后把原來的proxy_pass換成fastcgipass就可以了。
|
1
2
3
4
5
6
|
upstream apachephp { server www.quancha.cn:8080; #Apache1}....proxy_pass http://apachephp; |
替換成成
|
1
2
3
4
5
6
|
upstream php { server 127.0.0.1:9000;}...fastcgi_pass php; |
就可以把apache上跑的php遷移到php-fpm上來跑。
原以為這樣就可以高枕無憂了，遷移完成是也確實沒什么問題，但是如果你不去分析問題的根本原因在哪。
問題還是會找上門來，第二天nginx又報了504的gateway timeout。
這回沒apache什么事了吧，apache總算撇清了關(guān)系。
那應(yīng)該還是在nginx和php-fpm身上，查看nginx的錯誤日志，可以看到
|
1
2
3
|
[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: "www.quancha.cn" |
看到這里基本上就排除了nginx嫌疑，nginx是在等待php處理"GET /kd/open.php?company=chinapost&number=PA24977020344 HTTP/1.1"超時退出了。
馬上重啟php-fpm，問題沒有了，網(wǎng)站可以訪問了。
再次訪問該頁面，依然沒有響應(yīng)，但同時訪問別的頁面正常，該頁面刷新幾次后，整個網(wǎng)站都是bad gateway timeout了。
問題就縮小到這個php腳本上了。
|
1
|
netstat -napo |grep "php5-fpm" | wc -l |
查看php工作進程已經(jīng)達到了配置文件里的上限10，有種感覺就是大家都被open.php這個腳本卡住了。
這個腳本是干什么的呢？這個腳本就是采集快遞信息的，里面用到了php_curl。
PHP腳本如果執(zhí)行時間超過php.ini中的配置項max_execution_time不出結(jié)果就會強制退出。
查看了php.ini中max_execution_time確實配了，值為30。
萬能google派上用場了，經(jīng)過不斷google后得到下面這句話
set_time_limit()函數(shù)和配置指令max_execution_time只影響腳本本身執(zhí)行的時間。任何發(fā)生在諸如使用system()的系統(tǒng)調(diào)用，流操作，數(shù)據(jù)庫操作等的腳本執(zhí)行的最大時間不包括其中，當該腳本已運行。
就是說如果腳本中執(zhí)行了其它操作的時間是不計在腳本運行時間當中的，如果你沒設(shè)置超時，那么php就會一直等待調(diào)用的結(jié)果。
查看open.php源文件一看，果然沒有設(shè)置curl的超時時間。
增加如下兩行,重新刷新，后問題解決了。
|
1
2
|
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 10); //timeout on connectcurl_setopt($ch, CURLOPT_TIMEOUT, 10); //timeout on response |
當然，除了這種方法外，php-fpm里也提供參數(shù)供我們強制殺死長時間無結(jié)果的進程，只是該參數(shù)默認沒打開。
php-fpm的配置文件里可以設(shè)置一個參數(shù)request_terminate_timeout，請求終止的超時時間，當請求執(zhí)行超過這個時間就會被kill。
同時它還有個參數(shù)request_slowlog_timeout，用來記錄慢請求日志的。
命令行運行php的話，可以使用這段代碼
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
$real_execution_time_limit = 60; //時間限制if (pcntl_fork()){// some long time code which should be// terminated after $real_execution_time_limit seconds passed if it's not// finished by that time}else{sleep($real_execution_time_limit);posix_kill(posix_getppid(), SIGKILL);} |
