nginx優化（一）cpu相關

nginx優化

1. 增大nginx使用cpu的有效時長

   • 使其可以使用所有cpu資源
   • nginx進程間不爭搶cpu資源（繁忙的worker進程不該讓出，資源調度不該讓出資源）

   • 不和其餘進程爭搶資源（提高優先級使其佔用cpu時間更長，減小操做系統上耗資源的非nginx進程）

     • 阻塞api會致使主動讓出cpu（程序處理儘可能不進行阻塞）

     • 業務場景產生的阻塞api（同步讀網絡報文）

       • 同步：報文的發送和接受是同步進行的，發送後等待接受。 就是請求發送後須要等待響應

   • worker進程數量設置

     • 不能超過邏輯核數的4倍，通常設置爲什麼邏輯核數同樣便可
     • 兩核設置worker_processes 2;

   • 減小進程上下文切換

     • 主動切換的觸發條件，sleep，資源調度阻塞等
     • 被動切換，時間片耗盡（靜態優先級，nice，top命令中的NI列，值爲-20到19，動態優先級，top中的PR列，越低時間片越長）
     • worker_priority 0; main模塊設置優先級

   • 綁定cpu，多核cpu進程切換後，若是改變了運行cpu的核，會致使一些緩存丟失，綁定後利用固定的cpu響應用戶請求，能夠利用緩存(時間片輪訓致使運行的cpu核改變)

     • worker_cpu_affinity auto/cpumask; main模塊 auto爲自動綁定cpu和進程，cpumask是cpu掩碼，手工配置，有幾個nginx進程，寫幾個worker_cpu_affinity 0001 0010; #4核兩個進程 綁定不一樣的cpu

2. 鏈接數

   • io模型選擇

     • use epoll; use event，events模塊，配置須要使用什麼事件模型，不須要配置，會自動選擇一個最優的

   • 單個worker容許鏈接的數量

     • worker_connections number; number的計算方式 一個connection大約232個字節，event約有96個字節，一個鏈接共佔用大約232+96*2（讀寫兩個事件）B內存左右

   • worker進程最大打開文件數

     • 文件數會限制鏈接數，此參數收最大文件句柄數限制，超過了最大句柄數限制，就會報 too many open file錯誤，大併發時可能句柄不夠用
     • worker_rlimit_nofile number; events模塊設置
     • cat /proc/sys/fs/file-max 內核最大的文件數（默認是內存百分之10可打開的數量）
     • 單個進程可分配的最大文件數 cat /proc/sys/fs/nr_open 單個進程的不能超過內核的

   • 修改用戶的文件句柄數

     • ulimt -n 查看用戶的最大句柄數
     • ulimit -HSn 1000 修改，臨時修改，-H爲硬限制，-S是軟限制
     • /etc/security/limits.conf 永久修改，對用戶進行設置

     • nofile中的 hard limit不能超過單個進程的數量，若是超過了，沒法創建新的鏈接，xshell新窗口都打不開

       • 文件描述符設置：``

a.全部進程打開的文件描述符數不能超過/proc/sys/fs/file-max ,內核的文件描述符數
b.單個進程打開的文件描述符數不能超過user limit中nofile的soft limit，進程打開的數量受用戶的限制，可是設置的時候必需要設置的比用戶的大，進程的設置要比用戶大，用戶操做也須要一個文件操做描述符
c.nofile的soft limit不能超過其hard limit 
d. nofile的hard limit不能超過/proc/sys/fs/nr_open，進程必須大於用戶的