上課課件監(jiān)控分析以及優(yōu)化

1、nginx分析以及優(yōu)化安大叔2013-03-20目錄: nginx介紹 nginx安裝 nginx使用 nginx nginx分析調(diào)優(yōu)nginx目錄一款輕量級的Web 服務(wù)器/反向服務(wù)器及電子郵件（IMAP/POP3）服務(wù)器，并在一個BSD-like 協(xié)議下。由俄羅斯的程序設(shè)計師Igor Sysoev所開發(fā)，供大型的及搜尋引擎Rambler使用在國內(nèi)，已經(jīng)有新浪博客、新浪播客、搜狐通行證、網(wǎng)易、網(wǎng)易博客、金山逍遙網(wǎng)、金山愛詞霸、校內(nèi)網(wǎng)、YUPOO相冊、豆瓣、迅雷看看等多家Nginx 服務(wù)器。、頻道使用nginx簡介1、高并發(fā)連接：采用內(nèi)核poll模型，測試能夠支撐10萬并發(fā)連接，在實際生產(chǎn)環(huán)境

2、中跑到23萬并發(fā)連接數(shù)。2、內(nèi)存消耗少：在3萬并發(fā)連接下，開啟的10個Nginx 進程才消耗150M內(nèi)存（15M*10=150M），所以使得nginx 十分穩(wěn)定。3、配置文件非常簡單：風(fēng)格跟程序一樣通俗易懂。4、成本低廉：Nginx為開源軟件，可以使用。而購買F5 BIG-IP、NetScaler等硬件負(fù)載均衡交換機則需要十多萬至幾十萬。5、作為web服務(wù)器，nginx處理靜態(tài)文件、索引文件、自動索引的效率非常高6、高可用性：升級、更新對用戶可以做到完全不感知Nginx優(yōu)點單臺Nginx支撐了高達(dá)2.8萬的活動并發(fā)連接數(shù)Nginx單機并發(fā)能力1、使用序Nginx結(jié)合FastCGI運行 PHP、

3、JSP 、Perl等程2、使用Nginx作反向、負(fù)載均衡、規(guī)則過濾3、使用Nginx運行靜態(tài)HTML頁、圖片4、Nginx與其他新技術(shù)的結(jié)合應(yīng)用Nginx應(yīng)用類別建立用戶及組/usr/sbin/groupadd www/usr/sbin/useradd -g www www2安裝pcre 讓nginx支持rewrite 方便以后所需wget ftp:/ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-7.8.tar.gztar zxvf pcre-7.8.tar.gzcd pcre-7.8/./configuremake &&am

4、p; make installnginx安裝安裝nginxwgettar zxvf nginx-0.7.58.tar.gzcd nginx-0.7.58/./configure -user=www -group=www -prefix=/usr/local/webserver/ngin x -with-http_stub_status_module -with-http_ssl_module -with-cc-opt='-O2' -with-cpu-opt=opteronmake && make install注意上文中的-with-cc-opt='-O

5、2' -with-cpu-opt=opteron 這是編譯器優(yōu)化,目前最常用的是-02 而不是3.后面對應(yīng)CPU的型號,可參照:.gentoo.tw/index.php/HOWTO_CFLAGNginx安裝xx_17023 ?14164 ?14165 ?14166 ?14167 ?14168 ?14169 ?14170 ?14171 ?14172 ?# ps axf|fgrep nginx:|fgrep -v fgrepSR S R S R S R RS0:04 nginx: master process /usr/local/nginx/sbin/nginx -c 382:38380

6、:52381:09381:24381:13381:58381:44381:420:02_ nginx: worker process_ nginx: worker process_ nginx: worker process_ nginx: worker process_ nginx: worker process_ nginx: worker process_ nginx: worker process_ nginx: worker process_ nginx: cache manager processNginx運行實況Nginx運行實況master進程worker. 有異常時重新生成響

7、應(yīng)信號安全重新加載配置Binary更新切割日志Nginx運行實況可配置數(shù)量的worker進程-以非用戶運行-接收并處理用戶請求-接收master信號Cache manager進程管理-Cache-異步處理cache過期Cache loader(?)進程-啟動時加載已有cache數(shù)據(jù)信息Nginx運行實況Master&workerMasterworker大循環(huán)單進程單線程，區(qū)別于apache、tomcat、resin等其他中間件/web服務(wù)器。異步I/O，保證無阻塞驅(qū)動緩存機制Nginx工作模式內(nèi)存池struct ngx_pool_s ngx_pool_data_td;size_tngx

8、_pool_t ngx_chain_tmax;*current;*chain;ngx_pool_large_t*large;ngx_pool_cleanup_t*cleanup;ngx_log_t*log;考慮對齊生命周期零取整還減少內(nèi)存碎片開發(fā)過程中不必花費太多時間關(guān)注內(nèi)存管理的回收Nginx內(nèi)存管理Time Cache.減少gettimeofday調(diào)用次數(shù)字符串表達(dá)預(yù)生成秒未變時的簡化觸發(fā)更新讀寫競爭 (信號重入, 多線程)信號安全 (sig-safe)Nginx時間管理Nginx支持以下幾種信號：TERM,INT 快速關(guān)閉QUIT 從容關(guān)閉HUP重新加載配置. 使用新配置創(chuàng)建新的work

9、er進程, 安全舊的worker進程USR1 重新打開日志文件，在切割日志時用途較大USR2 平滑升級克執(zhí)行程序WINCH 從容關(guān)閉工作進程Reload 重新加載配置Nginx的信號啟動poechantubuntu:sudo ./sbin/nginx指定配置文件啟動/sbin/nginx -c /usr/local/nginx/conf/nginx.conf如果更改了配置就要重啟Nginx，要先關(guān)閉Nginx再打開？不是的，可以向Nginx信號，平滑重啟。平滑重啟命令：kill -HUP 住進稱號或進程或者使用/usr/nginx/sbin/nginx -s reload路徑注意，修改了配置文

10、件后最好先檢查一下修改過的配置文件是否正確，以免重啟后Nginx出現(xiàn)錯誤影響服務(wù)器穩(wěn)定運行。是否正確命令如下：nginx -t -c /usr/nginx/conf/nginx.conf或者/usr/nginx/sbin/nginx -tNginx配置Nginx啟動以及平滑重啟如果服務(wù)器正在運行的Nginx要進行升級、添加或刪除模塊時，我們需要停掉服務(wù)器并做相應(yīng)修改，這樣服務(wù)器就要在一段時間內(nèi)停止服務(wù)，Nginx可以在不停機的情況下進行各種升級動作而不影響服務(wù)器運行。步驟1：如 果升級Nginx程序，先用新程序替換舊程序文件，編譯安裝的話新程序直接編譯到Nginx安裝目錄中。步驟2：執(zhí)行命令k

11、ill -USR2 舊版程序的主進程號或進程文件名此時舊的Nginx主進程將會把的進程文件改名為.oldbin，然后執(zhí)行新版Nginx。新舊Nginx會同市運行，共同處理請求。這時要逐步停止舊版Nginx，輸入命令： kill -WINCH 舊版主進程號慢慢舊的工作進程就都會隨著任務(wù)執(zhí)行完畢而工作進程。此 時，我們可以決定使用新版還是恢復(fù)到舊版。不重載配置啟動新/舊工作進程，新版的Nginx的工作進程會逐漸取代舊版kill -HUP 舊/新版主進程號從容關(guān)閉舊/新進程kill -QUIT 舊/新主進程號如果此錯，提示還有進程沒有結(jié)束就用下面命令先關(guān)閉舊/新工作進程，再關(guān)閉主進程號：kill -

12、TERM 舊/新工作進程號這樣下來，如果要恢復(fù)到舊版本，只需要上面的幾個步驟都是操作新版主進程號，如果要用新版本就上面的幾個步驟都操作舊版主進程號就行了。上面就是Nginx的一些基本的操作，希望以后Nginx能有更好的方法來處理這些操作， 最好是令而不是向Nginx進程系統(tǒng)信號。NginxNginx平滑升級停止nginx主進程號ps -ef | grep nginx在進程列表里 面找master進程，它的編號就是主進程號了。信號從容停止Nginx： kill -QUIT 主進程號快速停止Nginx： kill -TERM 主進程號強制停止Nginx： pkill -9 nginx若在nginx

13、.conf配置了pid文件存放路徑則該文件存放的就是Nginx主進程號，如果沒指定則放在nginx的logs目錄下。有了pid文 件，我們就不用先Nginx的主進程號，而直接向Nginx發(fā)送信號了，命令如下：kill -信號類型 '/usr/nginx/logs/nginx.pid'Nginx停止reload熱升級需要回滾怎么辦給舊的masterHUP信號. 舊的master會在不重新進程配置的情況下重新創(chuàng)建worker給新的master信號熱升級回滾接收數(shù)據(jù)請求 查找虛機 查找location運行phase handler生成響應(yīng) 過濾響應(yīng)頭過濾響應(yīng)內(nèi)容響應(yīng)HTTP工作過程H

14、TTP工作typedef enum NGX_HTTP_POST_READ_PHASE = 0,/ real_ip, abtest, uuid, security_ieNGX_HTTP_SERVER_REWRITE_PHASE,/ rewrite(srv), antispider/ 內(nèi)置, 選擇location. 丟棄>client_max_body_size請求/ rewrite(loc)/ 內(nèi)置, 實施跳轉(zhuǎn). Loop -> FIND_CONFIG (最多10次)NGX_HTTP_FIND_CONFIG_PHASE,NGX_HTTP_REWRITE_PHASE,NGX_HTTP_

15、POST_REWRITE_PHASE,NGX_HTTP_PREACCESS_PHASE,/ degradation, limit_req, limit_zone, ip2loc, suvNGX_HTTP_ACCESS_PHASE,NGX_HTTP_POST_ACCESS_PHASE,/ access , auth_basic (satisfy)/ 內(nèi)置, 實施跳轉(zhuǎn)/ 內(nèi)置. 最后一個跳轉(zhuǎn)/ autoindex, dav, gzip_static, index, staticNGX_HTTP_TRY_FILES_PHASE,NGX_HTTP_CONTENT_PHASE,NGX_HTTP_LOG_

16、PHASE ngx_http_phases;/ log, scribeHTTP工作http -> output filterhttp一個的過程實例配置Nginx配置實例說明實例配置Nginx配置實例說明實例配置Nginx配置實例說明實例配置Nginx配置實例說明內(nèi)核優(yōu)化(/etc/sysctl.conf)配置文件優(yōu)化使用lua等Nginx優(yōu)化net.ipv4.tcp_max_tw_buckets = 6000timewait的數(shù)量，默認(rèn)是180000。net.ipv4.ip_local_port_range = 1024 65000系統(tǒng)打開的端口范圍。net.ipv4.tcp_tw_re

17、cycle = 1 啟用timewait快速回收。net.ipv4.tcp_tw_reuse = 1開啟重用。將TIME-WAIT sockets重新用于新的TCP連接。net.ipv4.tcp_syncookies = 1開啟SYN Cookies，當(dāng)出現(xiàn)SYN等待隊列溢出時，啟用cookies來處理。net.core.somaxconn = 262144web應(yīng)用中l(wèi)isten函數(shù)的backlog默認(rèn)會給我們內(nèi)核參數(shù)的net.core.somaxconn限制到128，而Nginx內(nèi)核參數(shù)定義的NGX_LISTEN_BACKLOG默認(rèn)為511，所以有必要調(diào)整這個值。dev_max_backl

18、og = 262144每個網(wǎng)絡(luò)接口接收數(shù)據(jù)包的速率比內(nèi)核處理這些包的速率快時， 送到隊列的數(shù)據(jù)包的最大數(shù)目。Nginx內(nèi)核優(yōu)化net.ipv4.tcp_max_orphans = 262144系統(tǒng)中最多有多少個TCP套接字不被關(guān)聯(lián)到任何一個用戶文件句柄上。如果超過這個數(shù)字，孤兒連接將即刻被復(fù)位并打印出警告信息。這個限制僅僅是為了防止簡單的DoS過分依靠它或者人為地減小這個值，更應(yīng)該增加這個值(如果增加了內(nèi)存之后)。net.ipv4.tcp_max_syn_backlog = 262144，不能的那些尚未收到客戶端確認(rèn)信息的連接請求的最大值。對于有128M內(nèi)存的系統(tǒng)而言，缺省值是1024，小內(nèi)存

19、的系統(tǒng)則是128。net.ipv4.tcp_timestamps = 0時間戳可以避免序列號的卷繞。一個1Gbps的鏈路肯定會遇到以前用過的序列號。時間戳能夠讓內(nèi)核接受這種“異?！钡臄?shù)據(jù)包。這里需要將其關(guān)掉。net.ipv4.tcp_synack_retries = 1為了打開對端的連接，內(nèi)核需要一個SYN并附帶一個回應(yīng)前面一個SYN的ACK。也就是所謂三次握手中的第二次握手。這個設(shè)置決定了內(nèi)核放棄連接之前net.ipv4.tcp_syn_retries = 1SYN+ACK包的數(shù)量。在內(nèi)核放棄建立連接之前net.ipv4.tcp_fin_timeout = 1SYN包的數(shù)量。如果套接字由本端

20、要求關(guān)閉，這個參數(shù)決定了它保持在FIN-WAIT-2狀態(tài)的時間。對端可以出錯并永遠(yuǎn)不關(guān)閉連接，甚至意外當(dāng)機。缺省值是60秒。2.2 內(nèi)核的通常值是180秒，你可以按這個設(shè)置，但要記住的是，即使你的字而內(nèi)存溢出的風(fēng)險，F(xiàn)IN- WAIT-2的但是它們的生存期長些。net.ipv4.tcp_keepalive_time = 30是一個輕載的WEB服務(wù)器，也有因為大量的死套接性比FIN-WAIT-1要小，因為它最多只能1.5K內(nèi)存，當(dāng)keepalive起用的時候，TCPkeepalive消息的頻度。缺省是2小時Nginx內(nèi)核優(yōu)化worker_processes 8;Nginx配置文件進程數(shù)，建議按照

21、cpu數(shù)目來指定，一般為它的倍數(shù)。worker_cpu_affi00000001 00000010 00000100 00001000 0001000000100000 01000000 10000000;為每個進程分配cpu，上例中將8個進程分配到8個cpu，當(dāng)然可以寫多個，或者將一個進程分配到多個cpu。worker_rlimit_nofile 102400;這個指令是指當(dāng)一個Nginx配置文件進程打開的最多文件描述符數(shù)目， 理論值應(yīng)該是最多打開文件數(shù)（ulimit -n）與Nginx進程數(shù)相除，但是Nginx分配請求并不是那么均勻，所以最好與ulimit -n的值保持一致。use epo

22、ll;使用epoll的I/O模型worker_connections 102400;每個進程的最多連接數(shù)，理論上每臺Nginx服務(wù)器的最大連接數(shù)為worker_processes*worker_connections。，在做反向worker_processes*worker_connections/4時為：Nginx配置優(yōu)化全局配置client_header_buffer_size 4k;客戶端請求頭部的緩沖區(qū)大小，這個可以根據(jù)你的系統(tǒng)分頁大小來設(shè)置，一般一個請求頭的大小超過1k，不過由于一般系統(tǒng)分頁都要大于1k，所以這里設(shè)置為分頁大小。分頁大小可以用命令getconf PAGESIZE取得。

23、open_file_cache max=102400 inactive=20s;這個將為打開文件指定緩存，默認(rèn)是沒有啟用的，max指定緩存數(shù)量，建議和打開文件數(shù)一致，inactive是指經(jīng)過多長時間文件沒被請求后刪除緩存。open_file_cache_valid 30s;這個是指多長時間檢查一次緩存的有效信息。open_file_cache_min_uses 1;open_file_cache指令中的inactive參數(shù)時間內(nèi)文件的最少使用次數(shù)，如果超過這個數(shù)字，文件描述符一直是在緩存中打開的，如上例，如果有一個文件在inactive時間內(nèi)一次沒被使用，它將被移除。關(guān)于內(nèi)核參數(shù)的優(yōu)化：Ngi

24、nx配置優(yōu)化HTTP服務(wù)器優(yōu)化client_max_body_size 8m;客戶端最大數(shù)據(jù)段大小server_names_hash_bucket_size 128; 服務(wù)器名的hash庫大小large_client_header_buffers 4 4k;用來指定客戶端請求中較大的消息頭的緩存最大數(shù)量和大小，4為個數(shù)，4k為最大緩存4個4kbSenfile 參數(shù)用于開啟高效文件傳輸模式，將tcp_nopush和y連個指令設(shè)置為on可以防止網(wǎng)絡(luò)阻塞tcp_nfastcgi_cache_path /usr/local/nginx/fastcgi_cache levels=1:2keys_zone

25、=TEST:10m緩存路徑，級別，檢測時間，活動時間Nginx配置優(yōu)化HTTP服務(wù)器優(yōu)化keepalive_timeout 60;用于設(shè)置客戶端連接保持活動的超時時間，超過這個時間后，服務(wù)器會關(guān)閉該Client_header_timeout用于設(shè)置客戶端請求頭超時時間，如果超過這個時間，客戶端還沒有錯誤”。任何數(shù)據(jù)，nginx將返回“R equit time out(408)Client_body_timeout用于設(shè)置客戶端請求主體 過這個時間，客戶端還沒有equit time out(408)錯誤”。send_timeout超時時間，默認(rèn)值為60,。如果超任何數(shù)據(jù)，nginx將返回“R用于

26、指定響應(yīng)客戶端的超時時間，這個超時僅限于兩個連接活動之前的時間，如果超過這個時間，客戶端沒有任何活動， nginx將會關(guān)系連接。Nginx配置優(yōu)化HTTP服務(wù)器優(yōu)化gzipon;用于設(shè)置開啟或者關(guān)閉gzip模塊，on表示開啟gzip壓縮，試試壓縮輸出數(shù)據(jù)流。gzip_min_length1k;用于設(shè)置壓縮的頁面最小字節(jié)數(shù)，頁面字節(jié)數(shù)從header頭的content-length中獲取，默認(rèn)值是0，不管頁面多大都進行壓縮。建議設(shè)置成大于1k的字節(jié)數(shù)，小于1k可能會越壓越大gzip_http_version1.1;用于設(shè)置識別HTTP協(xié)議版本，默認(rèn)是1.1，目前大部分瀏覽器已經(jīng)支持gzip壓縮，使

27、用默認(rèn)即可16k；gzip_buffers4表示申請4個為16k的內(nèi)存作為壓縮結(jié)果流緩存，默認(rèn)值是申請與原始數(shù)據(jù)大小相同的內(nèi)存空間來儲存gzip壓縮結(jié)果gzip_comp_level2;用來指定gzip壓縮比，1壓縮比最小，處理速度最快；9壓縮比最大，傳輸速度快，但處理最慢，也比較消耗CPUgzip_types *;用來指定壓縮類型，無論是否指定，“text/html”類型總是會被壓縮的gzip_varyon;該選項可以讓前端的緩存服務(wù)器經(jīng)過gzip壓縮的頁面，例如用Squid緩存經(jīng)過nginx壓縮的數(shù)據(jù)Nginx配置優(yōu)化HttpGzip輪詢默認(rèn)方式，每個請求按照時間先后順序逐一分配到不同的后

28、端服務(wù)器，如果后端某臺服務(wù)器宕機，故障系統(tǒng)被自動提出，使用戶Weight不受影響指定輪詢值， Weight值越大，分配到的個服務(wù)器性能不均的情況下ip_hash幾率越高，主要用于后端每每個請求按照的IP的hash進行分配，這樣來自同一個IP的訪客會固定一個后端服務(wù)器，有效解決了頁存在的session共享問題fair這個是比上面兩個更加智能的負(fù)載均衡算法，此種算法可以根據(jù)頁面大小和加載時間長短智能的進行負(fù)載均衡，也就是根據(jù)后端服務(wù)器的響應(yīng)時間來分配請求。響應(yīng)時間段的優(yōu)先分配。Nginx本身是不支持這種調(diào)度算法的，若需要使用必須url_hashnginx的upstream_fair模塊此方法按照u

29、rl的hash進行分配請求，使每個url定向到同一臺后端服務(wù)器，可以進一步提高后端緩存服務(wù)器的效率。Nginx本身是不支持這種調(diào)度算法的，若需要使用必須nginx的hash軟件包Nginx負(fù)載均策略upstream ip_hash;server :80;server :80 down;server :8009 max_fails=3 fail_timeout=20s;在HTTP upstream 模塊中，可以通過server指令指定后端服務(wù)器IP地址和端口，同時可以設(shè)定每個后端服務(wù)器在負(fù)載均衡調(diào)度中的狀態(tài)，常見狀態(tài)有-down，

30、表示當(dāng)前的server暫不參與負(fù)載均衡-backup，預(yù)留的備份機，當(dāng)其他所有非backup的或者忙的時候，才會請求backup出現(xiàn)故障-max_fails，請求失敗的次數(shù)，默認(rèn)為1，當(dāng)超過最大次數(shù)時，范圍proxy_next_ upstream 模塊定義的錯誤-fail_timeout，在經(jīng)歷了max_fails次失敗后，暫停服務(wù)的時間， max_fails可以和fail_timeout一起使用Nginx負(fù)載均策略fastcgi_connect_timeout 300;fastcgi連接存活時間fastcgi_send_timeout 300;存活時間fastcgifastcgi_read_

31、timeout 300;存活時間fastcgifastcgi_buffer_size 16k;fastcgi緩存塊大小fastcgi_buffers 16 16k; fastcgi緩存塊分配模式fastcgi_busy_buffers_size 16k; fastcgi繁忙時緩存塊大小fastcgi_temp_file_write_size 16k; 臨時文件寫入大小fastcgi_cache_valid 200 302 1h; 緩存失效時間fastcgi_cache_min_uses 1;緩存最小使用時間Nginx配置優(yōu)化Nginx 502的觸發(fā)條件502錯誤最通常的出現(xiàn)情況就是后端主機當(dāng)機

32、。在upstream配置里有這么一項配置：proxy_next_upstream，這個配置指定了nginx在從一個后端主機取數(shù)據(jù)遇到何種錯誤時會轉(zhuǎn)到下一個后端主機，里頭寫上的就是會出現(xiàn)502的所有情況拉，默認(rèn)是error timeout。error就是當(dāng)機、斷線之類的，timeout就是堵塞超時，比較容易理解。我一般是全寫上的：proxy_next_upstream error timeout invalid_header http_500 http_503;不過現(xiàn)在可能我要去掉http_500這一項了，http_500指定后端返回500錯誤時會轉(zhuǎn)一個主機，后端的jsp出錯的話，本來會打印一堆

33、stacktrace的錯誤信息，現(xiàn)在被502取代了。503錯誤就可以保留，因為后端通常是apache resin，如果apache死機就是error，但resin死機，僅僅是503，所以還是有必要保留的。Nginx一些錯誤解決502解決辦法查看當(dāng)前的PHP FastCGI進程數(shù)是否夠用：netstat -anpo | grep "php-cgi" | wc -l如果實際使用的“FastCGI進程數(shù)”接近預(yù)設(shè)的“FastCGI進程數(shù)”，那么，說明“FastCGI進程數(shù)”不夠用，需要增大。部分PHP程序的執(zhí)行時間超過了Nginx的等待時間，可以適當(dāng)增加nginx.conf配置文

34、件中FastCGI的timeout時間，例如：http fastcgi_connect_timeout 300;fastcgi_send_timeout 300;fastcgi_read_timeout 300;.php.ini中memory_limit設(shè)低了會出錯，修改了php.ini的memory_limit為64M，重啟nginx，發(fā)現(xiàn)好了，原來是PHP的內(nèi)存不足了。Nginx一些錯誤解決502解決辦法增加children的數(shù)量，并且將max_requests 設(shè)置未 0 或者一個比較大的值打開 /usr/local/php/etc/php-fpm.conf調(diào)大以下兩個參數(shù)(根據(jù)服務(wù)器實

35、際情況，過大也不行）<value name="max_children">5120</value> <value name="max_requests">600</value>增加緩沖區(qū)容量大小， client head buffer，fastcgi buffer size等如果主要是在一些post或者數(shù)據(jù)庫操作的時候出現(xiàn)502這種情況，而不是在靜態(tài)頁面操作中常見，那么可以查看一下php-fpm.conf設(shè)置中的一項：request_terminate_timeout ，這個值是max_execution_

36、time，就是fast-cgi的執(zhí)行0s時間。0s為關(guān)閉，就是無限執(zhí)行下去。（當(dāng)時裝的時候沒仔細(xì)看就改了一個數(shù)字）問題解決了，執(zhí)行很長時間也改這個值5s 看看效果。出錯了。優(yōu)化fastcgi中，還可以改php-cgi進程數(shù)不夠用、php執(zhí)行時間長、或者是php-cgi進程死掉，都會出現(xiàn)502錯誤。Nginx一些錯誤解決502Nginx 504 Gateway Time-out的含義是所請求的網(wǎng)關(guān)沒有請求到，簡單來說就是沒有請求到可以執(zhí)行的PHP-CGI。調(diào)整nginx.conf的設(shè)置fastcgi_connect_timeout 600;fastcgi_send_timeout 600;fas

37、tcgi_read_timeout 600; fastcgi_buffer_size 256k; fastcgi_buffers 16 256k; fastcgi_busy_buffers_size 512k;fastcgi_temp_file_write_size 512k;Nginx一些錯誤解決504在上傳時nginx返回了413錯誤在nginx.conf增加 client_max_body_size的相關(guān)設(shè)置, 這個值默認(rèn)是1m，可以增加到8m以增加提高文件大小限制； 如果運行的是php，那么還要檢查php.ini，這個大小client_max_body_size要和php.ini中的如

38、下值的最大值一致或者稍大，這樣就誤。post_max_size = 8M因為提交數(shù)據(jù)大小不一致出現(xiàn)的錯upload_max_filesize = 2MNginx一些錯誤解決413nginx400錯誤是由于request header過大，通常是由于cookie中寫入了較長的字符串所引起的。解決方法是不要在cookie里過多數(shù)據(jù)，如果實在需要的話可以考慮調(diào)整在nginx.conf中的client_header_buffer_size(默認(rèn)1k)若cookie太大，可能還需要調(diào)整large_client_header_buffers(默認(rèn)4k)，該參數(shù)說明如下： 請求行如果超過buffer，就會報

39、HTTP 414錯誤(URI Too Long) nginx接受最長的HTTP頭部大小必須比其中一個buffer大， 否則就會報400的HTTP錯誤(Bad Request)。Nginx一些錯誤解決400499對應(yīng)的是 “client has closed connection”。這很有可能是因為服務(wù)器端處理的時間過長，客戶端“不耐煩”了解決辦法：proxy_ignore_client_abort on;意思還有一種服務(wù)端不要主要主動關(guān)閉客戶端連接。是 確實是客戶端關(guān)閉了連接,或者說連接超時,無論你設(shè)置多少超時時間多沒用 原來是php進程不夠用了子進程一下php進程數(shù) 問題解決 默認(rèn)測試環(huán)境才

40、開5個Nginx一些錯誤解決499Nginx從0.7.48版本開始，支持了類似Squid的緩存功能；緩存把URL及相關(guān)組合當(dāng)作Key，用md5編碼哈希后保存； Nginx的Web緩存服務(wù)只能為指定URL或狀態(tài)碼設(shè)置過期時間，不支持類似Squid的PURGE指令，手動清除指定緩存頁面；采用MMAP實現(xiàn)，設(shè)置的緩存區(qū)大小不能超過物理內(nèi)存+SWAP的值。Nginx的緩存功能#設(shè)置Web緩存區(qū)名稱為cache_one，緩存空間大小為2000MB，1天一次緩存，單個文件超過5m不緩存。proxy_cache_path /data0/proxy_cache_path levels=1:2 keys_zon

41、e=cache_one:2000m inactive=1d max_size=5m;#注：proxy_temp_path和proxy_cache_path指定的路徑必須在同一分區(qū)proxy_temp_path /data0/proxy_temp_path;upstream my_server_pool serverserver :80 weight=1 max_fails=2 fail_timeout=30s; :80 weight=1 max_fails=2 fail_timeout=30s;反向中的Nginx.conf緩存配置serverlisten80;server_name ;location /proxy_set_header Host $host;proxy_set_header X-Forwarded-For $remote_addr;proxy_pass;location .*.(gif|jpg|jpeg|png|bmp|swf|js|css)$#對圖片、JS、CSS進行緩存，使用Web緩存區(qū)cache_one proxy_cache cache_one;反向中的Nginx