nginx的優化使用
1. 編譯安裝過程優化
1）.減小Nginx編譯後的文件大小
在編譯Nginx時，默認以debug模式進行，而在debug模式下會插入很多跟蹤和ASSERT之類的信息，編譯完成後，一個Nginx要有好幾兆字節。而在編譯前取消Nginx的debug模式，編譯完成後Nginx只有幾百千字節。因此可以在編譯之前，修改相關源碼，取消debug模式。具體方法如下：
在Nginx源碼文件被解壓後，找到源碼目錄下的auto/cc/gcc文件，在其中找到如下幾行：
- # debug
- CFLAGS=”$CFLAGS -g”
註釋掉或刪掉這兩行，即可取消debug模式。
2.為特定的CPU指定CPU類型編譯優化
在編譯Nginx時，默認的GCC編譯參數是“-O”，要優化GCC編譯，可以使用以下兩個參數：
- --with-cc-opt=‘-O3‘
- --with-cpu-opt=CPU #為特定的 CPU 編譯，有效的值包括：
pentium, pentiumpro, pentium3, # pentium4, athlon, opteron, amd64, sparc32, sparc64, ppc64
要確定CPU類型，可以通過如下命令：
- [[email protected] home]#cat /proc/cpuinfo | grep "model name"
2. 利用TCMalloc優化Nginx的性能
TCMalloc的全稱為Thread-Caching Malloc，是谷歌開發的開源工具google-perftools中的一個成員。與標準的glibc庫的Malloc相比，TCMalloc庫在內存分配效率和速度上要高很多，這在很大程度上提高了服務器在高並發情況下的性能，從而降低了系統的負載。下面簡單介紹如何為Nginx添加TCMalloc庫支持。
要安裝TCMalloc庫，需要安裝libunwind（32位操作系統不需要安裝）和google-perftools兩個軟件包，libunwind庫為基於64位CPU和操作系統的程序提供了基本函數調用鏈和函數調用寄存器功能。下面介紹利用TCMalloc優化Nginx的具體操作過程。
1).安裝libunwind庫
可以從http://download.savannah.gnu.org/releases/libunwind下載相應的libunwind版本，這裏下載的是libunwind-0.99-alpha.tar.gz。安裝過程如下：
- [[email protected] home]#tar zxvf libunwind-0.99-alpha.tar.gz
- [[email protected] home]# cd libunwind-0.99-alpha/
- [[email protected] libunwind-0.99-alpha]#CFLAGS=-fPIC ./configure
- [[email protected] libunwind-0.99-alpha]#make CFLAGS=-fPIC
- [[email protected] libunwind-0.99-alpha]#make CFLAGS=-fPIC install
2).安裝google-perftools
可以從http://google-perftools.googlecode.com下載相應的google-perftools版本，這裏下載的是google-perftools-1.8.tar.gz。安裝過程如下：
- [[email protected] home]#tar zxvf google-perftools-1.8.tar.gz
- [[email protected] home]#cd google-perftools-1.8/
- [[email protected] google-perftools-1.8]# ./configure
- [[email protected] google-perftools-1.8]#make && make install
- [[email protected] google-perftools-1.8]#echo "/usr/
local/lib" > /etc/ld.so.conf.d/usr_local_lib.conf - [[email protected] google-perftools-1.8]# ldconfig
至此，google-perftools安裝完成。
3).重新編譯Nginx
為了使Nginx支持google-perftools，需要在安裝過程中添加“–with-google_perftools_module”選項重新編譯Nginx。安裝代碼如下：
- [[email protected]]#./configure \
- >--with-google_perftools_module --with-http_stub_status_module --prefix=/opt/nginx
- [[email protected] nginx-0.7.65]#make
- [[email protected] nginx-0.7.65]#make install
到這裏Nginx安裝完成。
4).為google-perftools添加線程目錄
創建一個線程目錄，這裏將文件放在/tmp/tcmalloc下。操作如下：
- [[email protected] home]#mkdir /tmp/tcmalloc
- [[email protected] home]#chmod 0777 /tmp/tcmalloc
5).修改Nginx主配置文件
修改nginx.conf文件，在pid這行的下面添加如下代碼：
- #pid logs/nginx.pid;
- google_perftools_profiles /tmp/tcmalloc;
接著，重啟Nginx即可完成google-perftools的加載。
6).驗證運行狀態
為了驗證google-perftools已經正常加載，可通過如下命令查看：
- [root@ localhost home]# lsof -n | grep tcmalloc
- nginx 2395 nobody 9w REG 8,8 0 1599440 /tmp/tcmalloc.2395
- nginx 2396 nobody 11w REG 8,8 0 1599443 /tmp/tcmalloc.2396
- nginx 2397 nobody 13w REG 8,8 0 1599441 /tmp/tcmalloc.2397
- nginx 2398 nobody 15w REG 8,8 0 1599442 /tmp/tcmalloc.2398
由於在Nginx配置文件中設置worker_processes的值為4，因此開啟了4個Nginx線程，每個線程會有一行記錄。每個線程文件後面的數字值就是啟動的Nginx的pid值。
至此，利用TCMalloc優化Nginx的操作完成。
3.Nginx內核參數優化
內核參數的優化，主要是在Linux系統中針對Nginx應用而進行的系統內核參數優化。
下面給出一個優化實例以供參考。
- net.ipv4.tcp_max_tw_buckets = 6000
- net.ipv4.ip_local_port_range = 1024 65000
- net.ipv4.tcp_tw_recycle = 1
- net.ipv4.tcp_tw_reuse = 1
- net.ipv4.tcp_syncookies = 1
- net.core.somaxconn = 262144
- net.core.netdev_max_backlog = 262144
- net.ipv4.tcp_max_orphans = 262144
- net.ipv4.tcp_max_syn_backlog = 262144
- net.ipv4.tcp_synack_retries = 1
- net.ipv4.tcp_syn_retries = 1
- net.ipv4.tcp_fin_timeout = 1
- net.ipv4.tcp_keepalive_time = 30
將上面的內核參數值加入/etc/sysctl.conf文件中，然後執行如下命令使之生效：
- [root@ localhost home]#/sbin/sysctl -p
下面對實例中選項的含義進行介紹：
net.ipv4.tcp_max_tw_buckets ：選項用來設定timewait的數量，默認是180 000，這裏設為6000。
net.ipv4.ip_local_port_range:選項用來設定允許系統打開的端口範圍。在高並發情況否則端口號會不夠用。
net.ipv4.tcp_tw_recycle:選項用於設置啟用timewait快速回收.
net.ipv4.tcp_tw_reuse:選項用於設置開啟重用，允許將TIME-WAIT sockets重新用於新的TCP連接。
net.ipv4.tcp_syncookies:選項用於設置開啟SYN Cookies，當出現SYN等待隊列溢出時，啟用cookies進行處理。
net.core.somaxconn:選項的默認值是128， 這個參數用於調節系統同時發起的tcp連接數，在高並發的請求中，默認的值可能會導致鏈接超時或者重傳，因此，需要結合並發請求數來調節此值。
net.core.netdev_max_backlog:選項表示當每個網絡接口接收數據包的速率比內核處理這些包的速率快時，允許發送到隊列的數據包的最大數目。
net.ipv4.tcp_max_orphans:選項用於設定系統中最多有多少個TCP套接字不被關聯到任何一個用戶文件句柄上。如果超過這個數字，孤立連接將立即被復位並打印出警告信息。這個限制只是為了防止簡單的DoS攻擊。不能過分依靠這個限制甚至人為減小這個值，更多的情況下應該增加這個值。
net.ipv4.tcp_max_syn_backlog:選項用於記錄那些尚未收到客戶端確認信息的連接請求的最大值。對於有128MB內存的系統而言，此參數的默認值是1024，對小內存的系統則是128。
net.ipv4.tcp_synack_retries參數的值決定了內核放棄連接之前發送SYN+ACK包的數量。
net.ipv4.tcp_syn_retries選項表示在內核放棄建立連接之前發送SYN包的數量。
net.ipv4.tcp_fin_timeout選項決定了套接字保持在FIN-WAIT-2狀態的時間。默認值是60秒。正確設置這個值非常重要，有時即使一個負載很小的Web服務器，也會出現大量的死套接字而產生內存溢出的風險。
net.ipv4.tcp_syn_retries選項表示在內核放棄建立連接之前發送SYN包的數量。
如果發送端要求關閉套接字，net.ipv4.tcp_fin_timeout選項決定了套接字保持在FIN-WAIT-2狀態的時間。接收端可以出錯並永遠不關閉連接，甚至意外宕機。
net.ipv4.tcp_fin_timeout的默認值是60秒。需要註意的是，即使一個負載很小的Web服務器，也會出現因為大量的死套接字而產生內存溢出的風險。FIN-WAIT-2的危險性比FIN-WAIT-1要小，因為它最多只能消耗1.5KB的內存，但是其生存期長些。
net.ipv4.tcp_keepalive_time選項表示當keepalive啟用的時候，TCP發送keepalive消息的頻度。默認值是2（單位是小時）。
4.nginx.conf的參數優化
nginx要開啟的進程數 一般等於cpu的總核數 其實一般情況下開4個或8個就可以。
每個nginx進程消耗的內存10兆的模樣
worker_cpu_affinity
僅適用於linux，使用該選項可以綁定worker進程和CPU（2.4內核的機器用不了）
假如是8 cpu 分配如下：
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000
00100000 01000000 10000000
nginx可以使用多個worker進程，原因如下：
to use SMP
to decrease latency when workers blockend on disk I/O
to limit number of connections per process when select()/poll() is
used The worker_processes and worker_connections from the event sections
allows you to calculate maxclients value: k max_clients = worker_processes * worker_connections
worker_rlimit_nofile 102400;
每個nginx進程打開文件描述符最大數目 配置要和系統的單進程打開文件數一致,linux 2.6內核下開啟文件打開數為65535，worker_rlimit_nofile就相應應該填寫65535 nginx調度時分配請求到進程並不是那麽的均衡，假如超過會返回502錯誤。我這裏寫的大一點
use epoll
Nginx使用了最新的epoll（Linux 2.6內核）和kqueue（freebsd）網絡I/O模型，而Apache則使用的是傳統的select模型。
處理大量的連接的讀寫，Apache所采用的select網絡I/O模型非常低效。在高並發服務器中，輪詢I/O是最耗時間的操作 目前Linux下能夠承受高並發
訪問的Squid、Memcached都采用的是epoll網絡I/O模型。
worker_connections 65535;
每個工作進程允許最大的同時連接數 （Maxclient = work_processes * worker_connections）
keepalive_timeout 75
keepalive超時時間
這裏需要註意官方的一句話：
The parameters can differ from each other. Line Keep-Alive:
timeout=time understands Mozilla and Konqueror. MSIE itself shuts
keep-alive connection approximately after 60 seconds.
client_header_buffer_size 16k
large_client_header_buffers 4 32k
客戶請求頭緩沖大小
nginx默認會用client_header_buffer_size這個buffer來讀取header值，如果header過大，它會使用large_client_header_buffers來讀取
如果設置過小HTTP頭/Cookie過大 會報400 錯誤 nginx 400 bad request
求行如果超過buffer，就會報HTTP 414錯誤(URI Too Long) nginx接受最長的HTTP頭部大小必須比其中一個buffer大，否則就會報400的HTTP錯誤(Bad Request)。
open_file_cache max 102400
使用字段:http, server, location 這個指令指定緩存是否啟用,如果啟用,將記錄文件以下信息: ·打開的文件描述符,大小信息和修改時間. ·存在的目錄信息. ·在搜索文件過程中的錯誤信息 -- 沒有這個文件,無法正確讀取,參考open_file_cache_errors 指令選項:
·max - 指定緩存的最大數目,如果緩存溢出,最長使用過的文件(LRU)將被移除
例: open_file_cache max=1000 inactive=20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on;
open_file_cache_errors
語法:open_file_cache_errors on | off 默認值:open_file_cache_errors off 使用字段:http, server, location 這個指令指定是否在搜索一個文件是記錄cache錯誤.
open_file_cache_min_uses
語法:open_file_cache_min_uses number 默認值:open_file_cache_min_uses 1 使用字段:http, server, location 這個指令指定了在open_file_cache指令無效的參數中一定的時間範圍內可以使用的最小文件數,如 果使用更大的值,文件描述符在cache中總是打開狀態.
open_file_cache_valid
語法:open_file_cache_valid time 默認值:open_file_cache_valid 60 使用字段:http, server, location 這個指令指定了何時需要檢查open_file_cache中緩存項目的有效信息.
開啟gzip
gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.0;
gzip_comp_level 2;
gzip_types text/plain application/x-JavaScript text/css
application/xml;
gzip_vary on;
緩存靜態文件：
location ~* ^.+\.(swf|gif|png|jpg|js|css)$ {
root /usr/local/ku6/ktv/show.ku6.com/;
expires 1m;
}
nginx的優化使用