1).減少Nginx編譯後的文件大小css
在編譯Nginx時,默認以debug模式進行,而在debug模式下會插入不少跟蹤和ASSERT之類的信息,編譯完成後,一個Nginx要有好幾兆字節。而在編譯前取消Nginx的debug模式,編譯完成後Nginx只有幾百千字節。所以能夠在編譯以前,修改相關源碼,取消debug模式。具體方法以下:linux
在Nginx源碼文件被解壓後,找到源碼目錄下的auto/cc/gcc文件,在其中找到以下幾行:nginx
註釋掉或刪掉這兩行,便可取消debug模式。緩存
2.爲特定的CPU指定CPU類型編譯優化服務器
在編譯Nginx時,默認的GCC編譯參數是「-O」,要優化GCC編譯,可使用如下兩個參數:cookie
要肯定CPU類型,能夠經過以下命令:網絡
TCMalloc的全稱爲Thread-Caching Malloc,是谷歌開發的開源工具google-perftools中的一個成員。與標準的glibc庫的Malloc相比,TCMalloc庫在內存分配效率和速度上要高不少,這在很大程度上提升了服務器在高併發狀況下的性能,從而下降了系統的負載。下面簡單介紹如何爲Nginx添加TCMalloc庫支持。併發
要安裝TCMalloc庫,須要安裝libunwind(32位操做系統不須要安裝)和google-perftools兩個軟件包,libunwind庫爲基於64位CPU和操做系統的程序提供了基本函數調用鏈和函數調用寄存器功能。下面介紹利用TCMalloc優化Nginx的具體操做過程。app
1).安裝libunwind庫socket
能夠從http://download.savannah.gnu.org/releases/libunwind下載相應的libunwind版本,這裏下載的是libunwind-0.99-alpha.tar.gz。安裝過程以下:
2).安裝google-perftools
能夠從http://google-perftools.googlecode.com下載相應的google-perftools版本,這裏下載的是google-perftools-1.8.tar.gz。安裝過程以下:
至此,google-perftools安裝完成。
3).從新編譯Nginx
爲了使Nginx支持google-perftools,須要在安裝過程當中添加「–with-google_perftools_module」選項從新編譯Nginx。安裝代碼以下:
到這裏Nginx安裝完成。
4).爲google-perftools添加線程目錄
建立一個線程目錄,這裏將文件放在/tmp/tcmalloc下。操做以下:
5).修改Nginx主配置文件
修改nginx.conf文件,在pid這行的下面添加以下代碼:
接着,重啓Nginx便可完成google-perftools的加載。
6).驗證運行狀態
爲了驗證google-perftools已經正常加載,可經過以下命令查看:
因爲在Nginx配置文件中設置worker_processes的值爲4,所以開啓了4個Nginx線程,每一個線程會有一行記錄。每一個線程文件後面的數字值就是啓動的Nginx的pid值。
至此,利用TCMalloc優化Nginx的操做完成。
內核參數的優化,主要是在Linux系統中針對Nginx應用而進行的系統內核參數優化。
下面給出一個優化實例以供參考。
將上面的內核參數值加入/etc/sysctl.conf文件中,而後執行以下命令使之生效:
下面對實例中選項的含義進行介紹:
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(單位是小時)。
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;}