Nginx深度優化（二）

Nginx作爲現在最流行的Web應用程序，對其優化十分重要。通過Nginx初步優化、深度優化Nginx（一）已經可以對Nginx進行大量的優化來滿足基本的需要，但是作爲一名合格的運維工程師來說，僅僅掌握以上對Nginx進行優化的方法顯然是遠遠不足的。所以就需要本篇博文進一步對Nginx進行優化。

博文大綱：
一、安裝nginx服務器
二、Nginx配置優化
（1）Nginx 運行工作進程個數
（2）Nginx 事件處理模型
（3）開啓高效傳輸模式
（4）連接超時時間
（5）fastcgi調優
（6）expires 緩存調優
（7）防盜鏈
（8）內核參數優化

一、安裝nginx服務器

獲取Nginx軟件包

[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 來獲取配置選項詳細介紹

配置選項解釋：

--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命令常用的幾個選項：

-v：顯示版本信息；

-V：顯示版本信息及配置選項參數；

-t：測試配置文件是否有語法錯誤；

-T：測試配置文件並將配置文件顯示出來；

-q：在配置期間抑制非錯誤信息；

-s （stop, quit, reopen, reload ）：向主進程發送信號:停止、退出、重新打開、重新加載；

-c：設置配置文件；

-g：從配置文件中設置全局指令；

二、Nginx配置優化

[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相關進程。

關係圖如下：

從圖中也可以看出master是管理員，work進程纔是爲用戶提供服務的！

（1）Nginx 運行工作進程個數

建議：一般設置 CPU 的核心或者核心數 x2 。

[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進程

（2）Nginx 事件處理模型

[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 收到一個新連接通知後接受儘可能多的連接

（3）開啓高效傳輸模式

[root@localhost ~]# vim /usr/local/nginx/conf/nginx.conf
       ………………                           //省略部分內容
http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile        on;
    tcp_nopush     on;

配置項解釋：

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 在一個數據包裏發送所有頭文件，而不一個接一個的發送。

（4）連接超時時間

主要目的就是保護服務器資源、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;

配置項解釋：

keepalived_timeout：客戶端連接保持會話超時時間，超過這個時間，服務器斷開這個鏈接；
tcp_nodelay；也是防止網絡阻塞，不過要包涵在 keepalived 參數纔有效；
client_header_buffer_size 4k：客戶端請求頭部的緩衝區大小，這個可以根據你的系統分頁大小來設置，一般一個請求頭的大小不會超過 1k，不過由於一般系統分頁都要大於 1k，所以這裏設置爲分頁大小。分頁大小可以用命令 getconf PAGESIZE 取得；
open_file_cache max=102400 inactive=20s：這個將爲打開文件指定緩存，默認是沒有啓用的，max 指定緩存數量，建議和打開文件數一致，inactive 是指經過多長時間文件沒被請求後刪除緩存；
open_file_cache_valid 30s：這個是指多長時間檢查一次緩存的有效信息；
open_file_cache_min_uses 1：open_file_cache 指令中的 inactive 參數時間內文件的最少使用次數，如果超過這個數字，文件描述符一直是在緩存中打開的，如上例，如果有一個文件在 inactive 時間內一次沒被使用，它將被移除；
client_header_timeout：設置請求頭的超時時間。我們也可以把這個設置低些，如果超過這個時間沒有發送任何數據，nginx 將返回 request time out 的錯誤；
client_body_timeout：設置請求體的超時時間。我們也可以把這個設置低些，超過這個時間沒有發送任何數據，和上面一樣的錯誤提示；
reset_timeout_connection 告訴 nginx 關閉不響應的客戶端連接。這將會釋放那個客戶端所佔有的內存空間；
send_timeout 響應客戶端超時時間，這個超時時間僅限於兩個活動之間的時間，如果超過這個時間，客戶端沒有任何活動，nginx 關閉連接；
server_tokens 並不會讓 nginx 執行的速度更快，但它可以關閉在錯誤頁面中的 nginx 版本數字，這樣對於安全性是有好處的；
client_max_body_size 上傳文件大小限制；

（5）fastcgi調優

[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 服務器監聽端口與地址，可以是本機或者其它；

總結：

nginx 的緩存功能有：proxy_cache / fastcgi_cache ；
proxy_cache 的作用是緩存後端服務器的內容，可能是任何內容，包括靜態的和動態；
fastcgi_cache 的作用是緩存 fastcgi 生成的內容，很多情況是 php 生成的動態的內容；
proxy_cache 緩存減少了 nginx 與後端通信的次數，節省了傳輸時間和後端寬帶；
fastcgi_cache緩存減少了nginx與php的通信的次數，更減輕了php和數據庫(mysql)的壓力；

（6）expires 緩存調優

緩存，主要針對於圖片，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 功能優點：

expires 可以降低網站購買的帶寬，節約成本，同時提升用戶訪問體驗；
減輕服務的壓力，節約服務器成本，是 web 服務非常重要的功能。 expire 功能
缺點：被緩存的頁面或數據更新了，用戶看到的可能還是舊的內容，反而影響用戶體驗。解決辦法：第一個縮短緩存時間，例如：1 天，但不徹底，除非更新頻率大於 1 天；第二個對緩存的對象改名。

網站不希望被緩存的內容
1）網站流量統計工具；
2）更新頻繁的文件（google 的 logo）；

（7）防盜鏈

其實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的優化有詳細的介紹！

（8）內核參數優化

將所需的參數編寫在/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非法操作；

———————— 本文至此結束，感謝閱讀 ————————

Nginx深度優化（二）

一、安裝nginx服務器

二、Nginx配置優化

（1）Nginx 運行工作進程個數

（2）Nginx 事件處理模型

（3）開啓高效傳輸模式

（4）連接超時時間

（5）fastcgi調優

（6）expires 緩存調優

（7）防盜鏈

（8）內核參數優化

安裝Python

博客停止更新

Jenkins+Gitlab針對kubernetes集羣實現可持續集成

Jenkins+maven+gitlab+Tomcat自動部署更新及回滾

Kafka原理及Kafka羣集部署

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結