Nginx做爲如今最流行的Web應用程序,對其優化十分重要。經過Nginx初步優化、深度優化Nginx(一)已經能夠對Nginx進行大量的優化來知足基本的須要,可是做爲一名合格的運維工程師來講,僅僅掌握以上對Nginx進行優化的方法顯然是遠遠不足的。因此就須要本篇博文進一步對Nginx進行優化。php
博文大綱:
1、安裝nginx服務器
2、Nginx配置優化
(1)Nginx 運行工做進程個數
(2)Nginx 事件處理模型
(3)開啓高效傳輸模式
(4)鏈接超時時間
(5)fastcgi調優
(6)expires 緩存調優
(7)防盜鏈
(8)內核參數優化css
獲取Nginx軟件包html
[root@localhost ~]# yum -y install pcre-devel zlib-devel openssl-devel //安裝nginx依賴 [root@localhost ~]# useradd -s /sbin/nologin -M nginx //建立nginx用戶 [root@localhost ~]# tar zxf nginx-1.14.0.tar.gz -C /usr/src [root@localhost ~]# cd /usr/src/nginx-1.14.0/ [root@localhost nginx-1.14.0]# ./configure --prefix=/usr/local/nginx --user=nginx \ --group=nginx --with-http_dav_module --with-http_stub_status_module \ --with-http_addition_module --with-http_sub_module --with-http_flv_module \ --with-http_mp4_module --with-pcre --with-http_ssl_module \ --with-http_gzip_static_module && make && make install //對nginx進行編譯安裝,對源碼包進行編譯安裝時,可使用./configure --help 來獲取配置選項詳細介紹
配置選項解釋:node
- --with-http_dav_module:增長 PUT,DELETE,MKCOL:建立集合,COPY 和 MOVE 方法;
- --with-http_stub_status_module:獲取 Nginx 的狀態統計信息;
- --with-http_addition_module:做爲一個輸出過濾器,支持不徹底緩衝,分部分相應請求;
- --with-http_sub_module:容許一些其餘文本替換 Nginx 相應中的一些文本;
- --with-http_flv_module:提供支持 flv 視頻文件支持;
- --with-http_mp4_module:提供支持 mp4 視頻文件支持,提供僞流媒體服務端支持;
- --with-http_ssl_module:啓用 ngx_http_ssl_module;
[root@localhost ~]# ln -s /usr/local/nginx/sbin/nginx /usr/local/sbin //建立符號連接 [root@localhost ~]# nginx -t //檢查Nginx配置文件語法 [root@localhost ~]# nginx //啓動Nginx
對於nginx命令經常使用的幾個選項:mysql
- -v:顯示版本信息;
- -V:顯示版本信息及配置選項參數;
- -t:測試配置文件是否有語法錯誤;
- -T:測試配置文件並將配置文件顯示出來;
- -q:在配置期間抑制非錯誤信息;
- -s (stop, quit, reopen, reload ):向主進程發送信號:中止、退出、從新打開、從新加載;
- -c:設置配置文件;
- -g:從配置文件中設置全局指令;
[root@localhost ~]# ps -ef | grep nginx //列出Nginx程序所產生的進程 root 120790 1 0 22:49 ? 00:00:00 nginx: master process nginx nginx 120791 120790 0 22:49 ? 00:00:00 nginx: worker process root 120873 1928 0 22:57 pts/0 00:00:00 grep --color=auto nginx //第三條能夠忽略,它是由於grep命令所產生的
從顯示信息中能夠看出,work進程是Nginx程序用戶,但master進程是root。其中,master是監控進程,也稱爲Nginx的主進程;work進程是工做進程,部分狀況還會出現cache相關進程。nginx
關係圖以下:
從圖中也能夠看出master是管理員,work進程纔是爲用戶提供服務的!web
建議:通常設置 CPU 的核心或者核心數 x2 。sql
[root@localhost ~]# cat /proc/cpuinfo | grep processor | wc -l 1 //經過這條命令能夠查看到當前服務器的cpu是一個 [root@localhost ~]# vim /usr/local/nginx/conf/nginx.conf //編輯Nginx配置文件 worker_processes 2; //工做進程數,建議是CPU數或者是CPU個數的兩倍,最大能夠開啓8個 worker_cpu_affinity 01 10; //運行CPU親和力 worker_rlimit_nofile 65535; //最多打開的文件個數 [root@localhost ~]# ulimit -n 1024 //能夠看出系統默認限制打文件的個數是1024 文件個數除了nginx配置文件進行限制意外,還需修改文件資源限制文件,以下: [root@localhost ~]# vim /etc/security/limits.conf ……………… //省略部份內容 #<domain> <type> <item> <value> * soft nofile 65535 //添加軟限制打開文件的個數 * hard nofile 65535 //添加新限制打開文件的個數 * soft noproc 65535 //添加軟鏈接能夠打開的進程個數 * hard noproc 65535 //添加硬限制能夠打開的進程個數 [root@localhost ~]# su - //切換用戶便可生效 上一次登陸:三 12月 4 22:29:45 CST 2019從 192.168.1.253pts/0 上 [root@localhost ~]# ulimit -n 65535 //能夠看出文件個數已經變成了65535,證實修改的文件已經生效 [root@localhost ~]# nginx -s reload //從新加載nginx服務配置文件 [root@localhost ~]# ps -ef | grep nginx root 120790 1 0 22:49 ? 00:00:00 nginx: master process nginx nginx 121276 120790 0 23:21 ? 00:00:00 nginx: worker process nginx 121277 120790 0 23:21 ? 00:00:00 nginx: worker process root 121279 121226 0 23:22 pts/0 00:00:00 grep --color=auto nginx //因爲worker_processes設置爲2,能夠看出當前已經產生了兩個work進程
[root@localhost ~]# vim /usr/local/nginx/conf/nginx.conf ……………… //省略部份內容 events { use epoll; worker_connections 65535; multi_accept on; }
配置項解釋:數據庫
- use epol :使Nginx採用epoll事件模型;
- work_connections :是單個 worker 進程容許客戶端最大鏈接數,這個數值通常根據服務器性 能和內存來制定,實際最大值就是 worker 進程數乘以 work_connections 實際咱們填入一個 65535,足夠了,這些都算併發值,一個網站的併發達到這麼大的數量,也算一個大站了;
- multi_accept :告訴 nginx 收到一個新鏈接通知後接受盡量多的鏈接
[root@localhost ~]# vim /usr/local/nginx/conf/nginx.conf ……………… //省略部份內容 http { include mime.types; default_type application/octet-stream; sendfile on; tcp_nopush on;
配置項解釋:vim
- Include mime.types:媒體類型, include 只是一個在當前文件中包含另外一個文件內容的指令 ;
- default_type application/octet-stream:默認媒體類型足夠;
- sendfile on:開啓高效文件傳輸模式,sendfile 指令指定 nginx 是否調用 sendfile 函數來 輸出文件,對於普通應用設爲 on,若是用來進行下載等應用磁盤 IO 重負載應用,可設置爲 off,以平衡磁盤與網絡 I/O 處理速度,下降系統的負載。
注意:若是圖片顯示不正常把這個改爲 off。- tcp_nopush on; 必須在 sendfile 開啓模式纔有效,防止網路阻塞,積極的減小網絡報文 段的數量(告訴 nginx 在一個數據包裏發送全部頭文件,而不一個接一個的發送。
主要目的就是保護服務器資源、CPU、內存、控制鏈接數,由於創建鏈接也是須要消耗資源的。
[root@localhost ~]# vim /usr/local/nginx/conf/nginx.conf ……………… //省略部份內容 http { keepalive_timeout 60; tcp_nodelay on; client_header_buffer_size 4k; open_file_cache max=102400 inactive=20s; open_file_cache_valid 30s; open_file_cache_min_uses 1; client_header_timeout 15; client_body_timeout 15; reset_timedout_connection on; send_timeout 15; server_tokens off; client_max_body_size 10m;
配置項解釋:
[root@localhost ~]# vim /usr/local/nginx/conf/nginx.conf ……………… //省略部份內容 http { fastcgi_connect_timeout 600; fastcgi_send_timeout 600; fastcgi_read_timeout 600; fastcgi_buffer_size 64k; fastcgi_buffers 4 64k; fastcgi_busy_buffers_size 128k; fastcgi_temp_file_write_size 128k; fastcgi_temp_path /usr/local/nginx/nginx_tmp; fastcgi_intercept_errors on; fastcgi_cache_path /usr/local/nginx/fastcgi_cache levels=1:2 keys_zone=cache_fastcgi:128m inactive=1d max_size=10g;
配置項解釋:
- Cache: 寫入緩存區;
- Buffer: 讀取緩存區;
- fastcgi_connect_timeout 600:指定鏈接到後端 FastCGI 的超時時間;
- fastcgi_send_timeout 600:向 FastCGI 傳送請求的超時時間;
- fastcgi_read_timeout 600:指定接收 FastCGI 應答的超時時間;
- fastcgi_buffer_size 64k:指定讀取 FastCGI 應答第一部分須要用多大的緩衝區,默認的緩衝區 大小爲 fastcgi_buffers 指令中的每塊大小,能夠將這個值設置更小;
- fastcgi_buffers 4 64k:指定本地須要用多少和多大的緩衝區來緩衝 FastCGI 的應答請求,若是 一個 php 腳本所產生的頁面大小爲 256KB,那麼會分配 4 個 64KB 的緩衝區來緩存,若是頁 面大小大於 256KB,那麼大於 256KB 的部分會緩存到fastcgi_temp_path 指定的路徑中,可是 這並非好方法,由於內存中的數據處理速度要快於磁盤。通常這個值應該爲站點中 php 腳本所產生的頁面大小的中間值,若是站點大部分腳本所產生的頁面大小爲 256KB,那麼可 以把這個值設置爲「8 32K」、「4 64k」等;
- fastcgi_busy_buffers_size 128k:建議設置爲 fastcgi_buffers 的兩倍,繁忙時候的 buffer;
- fastcgi_temp_file_write_size 128k:在寫入 fastcgi_temp_path 時將用多大的數據塊,默認值是 fastcgi_buffers 的兩倍,該數值設置小時若負載上來時可能報 502 Bad Gateway;
- fastcgi_temp_path /usr/local/nginx1.10/nginx_tmp:緩存臨時目錄;
- fastcgi_intercept_errors on:這個指令指定是否傳遞 4xx 和 5xx 錯誤信息到客戶端,或者容許 nginx 使用 error_page 處理錯誤信息;
- fastcgi_cache_path /usr/local/nginx1.10/fastcgi_cache levels=1:2
keys_zone=cache_fastcgi:128m inactive=1d max_size=10g:fastcgi_cache 緩存目錄,能夠設置目錄層級,好比 1:2 會生成 16*256 個子目錄,cache_fastcgi 是這個緩存空間的名字,cache 是用多少內存(這樣熱門的 內容 nginx 直接放內存,提升訪問速度),inactive 表示默認失效時間,若是緩存數據在失效 時間內沒有被訪問,將被刪除,max_size 表示最多用多少硬盤空間;- fastcgi_cache cache_fastcgi:表示開啓 FastCGI 緩存併爲其指定一個名稱。開啓緩存很是有 用,能夠有效下降 CPU 的負載,而且防止 502 的錯誤放生。cache_fastcgi 爲 proxy_cache_path 指令建立的緩存區名稱;
- fastcgi_cache_valid 200 302 1h:用來指定應答代碼的緩存時間,實例中的值表示將 200 和 302 應答緩存一小時,要和 fastcgi_cache 配合使用;
- fastcgi_cache_valid 301 1d:將 301 應答緩存一天 ;
- fastcgi_cache_valid any 1m:將其餘應答緩存爲 1 分鐘;
- fastcgi_cache_min_uses 1:該指令用於設置通過多少次請求的相同 URL 將被緩存;
- fastcgi_cache_key http://$host$request_uri :該指令用來設置web緩存的Key值,nginx根據Key 值 md5 哈希存儲.通常根據$host(域名)、$request_uri(請求的路徑)等變量組合成 proxy_cache_key;
- fastcgi_pass:指定 FastCGI 服務器監聽端口與地址,能夠是本機或者其它;
總結:
緩存,主要針對於圖片,css,js 等元素更改機會比較少的狀況下使用,特別是圖片,佔用帶寬大,咱們徹底能夠設置圖片在瀏覽器本地緩存 365d,css,js,html 能夠緩存個 10 來天,這樣用戶第一次打開加載慢一點,第二次,就很是快了!緩存的時候,咱們須要將須要緩存的拓展名列出來。
Expires 緩存配置在 server 字段裏面。以下:
location ~ .(ico|jpe?g|gif|png|bmp|swf|flv)$ {
expires 30d; //緩存時間爲30天
#log_not_found off; //是否在 error_log 中記錄不存在的錯誤
access_log off; //不記錄日誌
}
location ~ .(js|css)$ {
expires 7d;
log_not_found off;
access_log off;
}
expire 功能優勢:
網站不但願被緩存的內容
1)網站流量統計工具;
2)更新頻繁的文件(google 的 logo);
其實Nginx的防盜鏈與Apache的防盜鏈原理是如出一轍,只是配置文件略微有點不一樣而已。
location ~* ^.+\.(jpg|gif|png|swf|flv|wma|wmv|asf|mp3|mmf|zip|rar)$ { valid_referers none blocked www.benet.com benet.com; if ($invalid_referer) { #return 302 http://www.benet.com/img/nolink.jpg; //要麼定義到另外一個網站,返回狀態碼爲302 return 404; //要麼訪問狀態碼404 break; } access_log off; }
很簡單的,這裏就不進行配置驗證了,對防盜鏈不瞭解的朋友能夠參考深度優化Apache其中對Apache的優化有詳細的介紹!
將所需的參數編寫在/etc/sysctl.conf 文件中,使其生效便可!
經常使用的參數有:
- fs.file-max = 999999:這個參數表示進程(好比一個 worker 進程)能夠同時打開的最大句柄數,這個參數直線限制最大併發鏈接數,需根據實際狀況配置;
- net.ipv4.tcp_max_tw_buckets = 6000:這個參數表示操做系統容許 TIME_WAIT 套接字數量的最大值,若是超過這個數字,TIME_WAIT 套接字將馬上被清除並打印警告信息。該參數默認爲 180000,過多的 TIME_WAIT 套接字會使 Web 服務器變慢;
注意:主動關閉鏈接的服務端會產生 TIME_WAIT 狀態的鏈接;- net.ipv4.ip_local_port_range = 1024 65000:容許系統打開的端口範圍;
- net.ipv4.tcp_tw_recycle = 1:啓用 timewait 快速回收;
- net.ipv4.tcp_tw_reuse = 1:開啓重用。容許將 TIME-WAIT sockets 從新用於新的 TCP 鏈接。這對於服務器來講頗有意義,由於服務器上總會有大量 TIME-WAIT 狀態的鏈接;
- net.ipv4.tcp_keepalive_time = 30:這個參數表示當 keepalive 啓用時,TCP 發送 keepalive 消息的頻度。默認是 2 小時,若將其設置的小一些,能夠更快地清理無效的鏈接;
- net.ipv4.tcp_syncookies = 1:開啓 SYN Cookies,當出現 SYN 等待隊列溢出時,啓用 cookies 來處理;
- net.core.somaxconn = 40960:web 應用中 listen 函數的 backlog 默認會給咱們內核參數的net.core.somaxconn 限制到 128,而 nginx 定義的 NGX_LISTEN_BACKLOG 默認爲 511,因此有必要調整這個值;
注意:對於一個 TCP 鏈接,Server 與 Client 須要經過三次握手來創建網絡鏈接.當三次握手成功後,咱們能夠看到端口的狀態由 LISTEN 轉變爲 ESTABLISHED,接着這條鏈路上就能夠開始傳送數據了.每個處於監聽(Listen)狀態的端口,都有本身的監聽隊列.監聽隊列的長度與如somaxconn 參數和使用該端口的程序中 listen()函數有關;
somaxconn 參數:定義了系統中每個端口最大的監聽隊列的長度,這是個全局的參數,默認值爲 128,對於一個常常處理新鏈接的高負載 web 服務環境來講,默認的 128 過小了。大多數環境這個值建議增長到 1024 或者更多。大的偵聽隊列對防止拒絕服務也會有所幫助;- net.core.netdev_max_backlog = 262144:每一個網絡接口接收數據包的速率比內核處理這些包的速率快時,容許送到隊列的數據包的最大數目;
- net.ipv4.tcp_max_syn_backlog = 262144:這個參數標示 TCP 三次握手創建階段接受 SYN 請求隊列的最大長度,默認爲 1024,將其設置得大一些可使出現 Nginx 繁忙來不及 accept 新鏈接的狀況時,Linux 不至於丟失客戶端發起的鏈接請求;
- net.ipv4.tcp_rmem = 10240 87380 12582912:這個參數定義了 TCP 接受緩存(用於 TCP 接受滑動窗口)的最小值、默認值、最大值;
- net.ipv4.tcp_wmem = 10240 87380 12582912:這個參數定義了 TCP 發送緩存(用於 TCP 發送滑動窗口)的最小值、默認值、最大值;
- net.core.rmem_default = 6291456:這個參數表示內核套接字接受緩存區默認的大小;
- net.core.wmem_default = 6291456:這個參數表示內核套接字發送緩存區默認的大小;
- net.core.rmem_max = 12582912:這個參數表示內核套接字接受緩存區的最大大小;
- net.core.wmem_max = 12582912:這個參數表示內核套接字發送緩存區的最大大小;
- net.ipv4.tcp_syncookies = 1:該參數與性能無關,用於解決 TCP 的 SYN非法操做;
———————— 本文至此結束,感謝閱讀 ————————