一次nginx文件打開數的問題排查處理

原創 馬昌偉 2024-05-18 14:17

 

現象：nginx域名配置合併之後，發現consul-template無法完成nginx重載，然後發現需要重啓nginx，才能讓配置生效。

注意：下次哪個服務有報錯，就看重啓時所有日誌輸出，各種情況日誌輸出。不要忽略細節。很多時候其實已經看到了問題，卻沒有深入查看問題。

 

 

查看進程最大打開文件個數

#cat /proc/31146/limits|grep "Max open files"

Max open files            1024                 4096                 files  

# cat /usr/lib/systemd/system/openresty.service
[Unit]

[Service]
LimitNOFILE=655350

[Install]

#

 

consul-template無法重載，是因爲進程本身無法重載，進程無法打開文件了

[[email protected] mcw]# ps -ef|grep nginx
root      3114     1  0 02:19 ?        00:00:00 nginx: master process /usr/local/openresty/nginx/sbin/nginx
nobody    3115  3114  0 02:19 ?        00:00:00 nginx: worker process
nobody    3116  3114  0 02:19 ?        00:00:00 nginx: worker process
root      3132  9036  0 02:19 pts/1    00:00:00 grep --color=auto nginx
[root@vm-nginx003.mm.machangwei.com mcw]# 
[root@vm-nginx003.mm.machangwei.com mcw]# systemctl reload openresty
[root@vm-nginx003.mm.machangwei.com mcw]# ps -ef|grep nginx
root      3114     1  2 02:19 ?        00:00:00 nginx: master process /usr/local/openresty/nginx/sbin/nginx
nobody    3115  3114  0 02:19 ?        00:00:00 nginx: worker process is shutting down
nobody    3116  3114  0 02:19 ?        00:00:00 nginx: worker process is shutting down
nobody    3171  3114  4 02:20 ?        00:00:00 nginx: worker process
nobody    3172  3114  4 02:20 ?        00:00:00 nginx: worker process
root      3175  9036  0 02:20 pts/1    00:00:00 grep --color=auto nginx
[root@vm-nginx003.mm.machangwei.com mcw]#

 

查看日誌報錯：有打開太多文件數

[[email protected] mcw]# ls /data/logs/nginx/nginx_error.log
/data/logs/nginx/nginx_error.log
[root@vm-nginx003.mm.machangwei.com mcw]# vim /data/logs/nginx/nginx_error.log
2024/05/18 00:59:57 [notice] 15124#15124: exit
2024/05/18 00:59:57 [notice] 1586#1586: signal 17 (SIGCHLD) received from 15123
2024/05/18 00:59:57 [notice] 1586#1586: signal 14 (SIGALRM) received
2024/05/18 00:59:57 [notice] 1586#1586: worker process 15123 exited with code 0
2024/05/18 00:59:57 [notice] 1586#1586: worker process 15124 exited with code 0
2024/05/18 00:59:57 [notice] 1586#1586: exit
2024/05/18 01:00:15 [notice] 15493#15493: using the "epoll" event method
2024/05/18 01:00:15 [notice] 15493#15493: openresty/1.19.3.1
2024/05/18 01:00:15 [notice] 15493#15493: built by gcc 8.3.1 20190311 (Red Hat 8.3.1-3) (GCC) 
2024/05/18 01:00:15 [notice] 15493#15493: OS: Linux 5.4.65-200.el7.x86_64
2024/05/18 01:00:15 [notice] 15493#15493: getrlimit(RLIMIT_NOFILE): 1024:4096
2024/05/18 01:00:15 [notice] 15496#15496: start worker processes
2024/05/18 01:00:15 [notice] 15496#15496: start worker process 15497
2024/05/18 01:00:15 [notice] 15496#15496: start worker process 15498
2024/05/18 01:00:29 [notice] 15496#15496: signal 1 (SIGHUP) received from 15545, reconfiguring
2024/05/18 01:00:29 [notice] 15496#15496: reconfiguring
2024/05/18 01:00:29 [warn] 15496#15496: conflicting server name "test-content-review.mcwcn.com" on 0.0.0.0:80, ignored
2024/05/18 01:00:29 [warn] 15496#15496: could not build optimal server_names_hash, you should increase either server_names_hash_max_size: 51
2 or server_names_hash_bucket_size: 128; ignoring server_names_hash_bucket_size
2024/05/18 01:00:29 [emerg] 15496#15496: open() "/data/logs/nginx/dev-account-mcwapps_error.log" failed (24: Too many open files)
2024/05/18 01:01:03 [notice] 15496#15496: signal 1 (SIGHUP) received from 15723, reconfiguring
2024/05/18 01:01:03 [notice] 15496#15496: reconfiguring
2024/05/18 01:01:03 [warn] 15496#15496: conflicting server name "test-content-review.mcwcn.com" on 0.0.0.0:80, ignored
2024/05/18 01:01:03 [warn] 15496#15496: could not build optimal server_names_hash, you should increase either server_names_hash_max_size: 51
2 or server_names_hash_bucket_size: 128; ignoring server_names_hash_bucket_size
2024/05/18 01:01:03 [emerg] 15496#15496: open() "/data/logs/nginx/dev-account-mcwapps_error.log" failed (24: Too many open files)
2024/05/18 01:01:14 [notice] 15496#15496: signal 1 (SIGHUP) received from 15750, reconfiguring
2024/05/18 01:01:14 [notice] 15496#15496: reconfiguring
2024/05/18 01:00:29 [warn] 15496#15496: conflicting server name "test-content-review.mcwcn.com" on 0.0.0.0:80, ignored
2024/05/18 01:00:29 [warn] 15496#15496: could not build optimal server_names_hash, you should increase either server_names_hash_max_size: 51
2 or server_names_hash_bucket_size: 128; ignoring server_names_hash_bucket_size
2024/05/18 01:00:29 [emerg] 15496#15496: open() "/data/logs/nginx/dev-account-mcwapps_error.log" failed (24: Too many open files)
2024/05/18 01:01:03 [notice] 15496#15496: signal 1 (SIGHUP) received from 15723, reconfiguring
2024/05/18 01:01:03 [notice] 15496#15496: reconfiguring
2024/05/18 01:01:03 [warn] 15496#15496: conflicting server name "test-content-review.mcwcn.com" on 0.0.0.0:80, ignored
2024/05/18 01:01:03 [warn] 15496#15496: could not build optimal server_names_hash, you should increase either server_names_hash_max_size: 51
2 or server_names_hash_bucket_size: 128; ignoring server_names_hash_bucket_size
2024/05/18 01:01:03 [emerg] 15496#15496: open() "/data/logs/nginx/dev-account-mcwapps_error.log" failed (24: Too many open files)
2024/05/18 01:01:14 [notice] 15496#15496: signal 1 (SIGHUP) received from 15750, reconfiguring
2024/05/18 01:01:14 [notice] 15496#15496: reconfiguring
2024/05/18 01:01:14 [warn] 15496#15496: conflicting server name "test-content-review.mcwcn.com" on 0.0.0.0:80, ignored
2024/05/18 01:01:14 [warn] 15496#15496: could not build optimal server_names_hash, you should increase either server_names_hash_max_size: 51
2 or server_names_hash_bucket_size: 128; ignoring server_names_hash_bucket_size
2024/05/18 01:01:14 [emerg] 15496#15496: open() "/data/logs/nginx/dev-account-mcwapps_error.log" failed (24: Too many open files)
2024/05/18 01:02:46 [notice] 15496#15496: signal 1 (SIGHUP) received from 16163, reconfiguring
2024/05/18 01:02:46 [notice] 15496#15496: reconfiguring
2024/05/18 01:02:46 [warn] 15496#15496: conflicting server name "test-content-review.mcwcn.com" on 0.0.0.0:80, ignored
2024/05/18 01:02:46 [warn] 15496#15496: could not build optimal server_names_hash, you should increase either server_names_hash_max_size: 51
2 or server_names_hash_bucket_size: 128; ignoring server_names_hash_bucket_size
2024/05/18 01:02:46 [emerg] 15496#15496: open() "/data/logs/nginx/dev-account-mcwapps_error.log" failed (24: Too many open files)
2024/05/18 01:03:54 [notice] 15496#15496: signal 3 (SIGQUIT) received from 16526, shutting down
2024/05/18 01:03:54 [notice] 15498#15498: gracefully shutting down
2024/05/18 01:03:54 [notice] 15498#15498: signal 15 (SIGTERM) received from 1, exiting
2024/05/18 01:03:54 [notice] 15496#15496: signal 15 (SIGTERM) received from 1, exiting
2024/05/18 01:03:54 [notice] 15497#15497: signal 15 (SIGTERM) received from 1, exiting

 

這裏查看的，不是那個進程所能打開的最大個數

[[email protected] mcw]# cat /etc/security/limits.conf
# End of file
* soft nproc 655350
* hard nproc 655350
* soft nofile 655350
* hard nofile 655350
[root@vm-nginx003.mm.machangwei.com mcw]#
[[email protected] mcw]# sysctl -a|grep fs.file-max
fs.file-max = 7930900
[root@vm-nginx003.mm.machangwei.com mcw]#

找到進程id,查看進程可以打開的最大個數，雖然nginx配置了worker可以打開很多個文件，但是也沒有設置master進程打開文件個數

[[email protected] mcw]# ps -ef|grep nginx
root     31146     1  0 02:01 ?        00:00:00 nginx: master process /usr/local/openresty/nginx/sbin/nginx
nobody   31147 31146  0 02:01 ?        00:00:00 nginx: worker process
nobody   31148 31146  0 02:01 ?        00:00:00 nginx: worker process
root     32633  9036  0 02:07 pts/1    00:00:00 grep --color=auto nginx
[root@vm-nginx003.mm.machangwei.com mcw]# 

[root@vm-nginx003.mm.machangwei.com mcw]# cat /proc/31146/limits|grep "Max open files"
Max open files            1024                 4096                 files     
[root@vm-nginx003.mm.machangwei.com mcw]#

master進程是systemd啓動，systemd啓動的進程需要設置打開文件大小個數，新增配置項LimitNOFILE=655350，把數弄大點

[[email protected] mcw]# cat /usr/lib/systemd/system/openresty.service
[Unit]
Description=The OpenResty Application Platform
After=syslog.target network-online.target remote-fs.target nss-lookup.target
Wants=network-online.target

[Service]
LimitNOFILE=655350
Type=forking
PIDFile=/usr/local/openresty/nginx/logs/nginx.pid
ExecStartPre=/usr/local/openresty/nginx/sbin/nginx -t
ExecStart=/usr/local/openresty/nginx/sbin/nginx
#ExecStart=/bin/openresty
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true

[Install]
WantedBy=multi-user.target
[root@vm-nginx003.mm.machangwei.com mcw]#

重啓之後，查看進程最大支持打開文件個數，已經被修改了

[[email protected] mcw]# ps -ef|grep nginx
root      3114     1  0 02:19 ?        00:00:00 nginx: master process /usr/local/openresty/nginx/sbin/nginx
nobody    3223  3114  0 02:20 ?        00:00:00 nginx: worker process
nobody    3224  3114  0 02:20 ?        00:00:00 nginx: worker process
root      3618  9036  0 02:21 pts/1    00:00:00 grep --color=auto nginx
[root@vm-nginx003.mm.machangwei.com mcw]# 
[root@vm-nginx003.mm.machangwei.com mcw]# cat /proc/3114/limits|grep "Max open files"
Max open files            655350               655350               files     
[root@vm-nginx003.mm.machangwei.com mcw]#

多次重載nginx,可以看到舊的子進程在關閉，新的子進程在啓動代替它

[[email protected] mcw]# ps -ef|grep nginx
root      3114     1  0 02:19 ?        00:00:00 nginx: master process /usr/local/openresty/nginx/sbin/nginx
nobody    3115  3114  0 02:19 ?        00:00:00 nginx: worker process
nobody    3116  3114  0 02:19 ?        00:00:00 nginx: worker process
root      3132  9036  0 02:19 pts/1    00:00:00 grep --color=auto nginx
[root@vm-nginx003.mm.machangwei.com mcw]# 
[root@vm-nginx003.mm.machangwei.com mcw]# systemctl reload openresty
[root@vm-nginx003.mm.machangwei.com mcw]# ps -ef|grep nginx
root      3114     1  2 02:19 ?        00:00:00 nginx: master process /usr/local/openresty/nginx/sbin/nginx
nobody    3115  3114  0 02:19 ?        00:00:00 nginx: worker process is shutting down
nobody    3116  3114  0 02:19 ?        00:00:00 nginx: worker process is shutting down
nobody    3171  3114  4 02:20 ?        00:00:00 nginx: worker process
nobody    3172  3114  4 02:20 ?        00:00:00 nginx: worker process
root      3175  9036  0 02:20 pts/1    00:00:00 grep --color=auto nginx
[root@vm-nginx003.mm.machangwei.com mcw]#

 

systemd 啓動配置openresty.service，配置的是master打開的文件個數，nginx.conf裏面設置的是worker打開的文件個數

# ps -ef|grep nginx
root      3114     1  0 02:19 ?        00:00:00 nginx: master process /usr/local/openresty/nginx/sbin/nginx
nobody    3223  3114  0 02:20 ?        00:00:01 nginx: worker process
nobody    3224  3114  0 02:20 ?        00:00:01 nginx: worker process
root     14607  9036  0 03:07 pts/1    00:00:00 grep --color=auto nginx
# 
# cat /proc/3114/limits |grep "Max open files"
Max open files            655350               655350               files     
# cat /proc/3223/limits |grep "Max open files"
Max open files            51200                51200                files     
#

 

 

=====

參考信息如下：

 

nginx重載，/bin/kill -s HUP 不生效

 

在Nginx中，/bin/kill -s HUP 命令通常用於重新加載Nginx的配置文件，而不是掛起（suspend）Nginx進程。如果你發現這個命令沒有生效，可能是由以下幾個原因造成的：

  1. 錯誤的進程ID：確保你發送HUP信號的進程ID（PID）是正確的。你可以通過 ps 命令查找Nginx的主進程ID。

    bash複製代碼
      ps aux | grep nginx

    通常，你會看到類似 nginx master process 的行，後面跟着的就是主進程的PID。

  2. 權限問題：你可能沒有足夠的權限來發送信號給Nginx進程。確保你具有發送信號到該進程的權限，或者使用root用戶來執行該命令。

  3. Nginx進程未運行：確保Nginx服務正在運行。你可以使用 systemctl status nginx（對於使用systemd的系統）或 service nginx status（對於使用SysVinit的系統）來檢查Nginx的狀態。

  4. Nginx配置文件有錯誤：如果Nginx的配置文件存在語法錯誤，nginx -s reload 或 /bin/kill -s HUP [nginx_pid] 可能不會生效，因爲Nginx無法重新加載一個無效的配置。你可以使用 nginx -t 來測試配置文件的語法是否正確。

  5. Nginx不是通過init系統啓動的：如果Nginx不是通過init系統（如systemd或SysVinit）啓動的，那麼它可能不會響應HUP信號。確保Nginx是通過標準的init系統服務來管理的。

  6. SELinux或AppArmor安全策略：如果你的系統啓用了SELinux或AppArmor這樣的安全模塊，它們可能會阻止進程之間的信號傳遞。檢查相關的安全策略或日誌文件以確認是否有相關的限制。

  7. 其他系統級限制：有些系統級的限制（如cgroups、資源限制等）可能會阻止進程接收或處理信號。

爲了解決這個問題，你可以嘗試以下步驟：

  • 使用正確的Nginx進程ID重新發送HUP信號。
  • 確保你具有發送信號所需的權限。
  • 檢查Nginx的狀態和日誌文件，確認它是否正在運行且沒有錯誤。
  • 使用 nginx -t 測試Nginx配置文件的語法是否正確。
  • 如果可能的話，嘗試通過init系統（如 systemctl reload nginx）來重新加載Nginx配置。
  • 檢查SELinux或AppArmor的安全策略，確保它們沒有阻止信號傳遞。
  • 如果以上步驟都無法解決問題，考慮重啓Nginx服務（但請注意，這會導致短暫的服務中斷）。

 

nginx報錯 open() "_error.log" failed (24: Too many open files)

 

Nginx 報錯 "open() "_error.log" failed (24: Too many open files)" 意味着 Nginx 進程嘗試打開的文件數量超過了系統或用戶級別的限制。在 Linux 系統中，每個進程和每個用戶都有打開文件數量的限制。

要解決這個問題，你可以採取以下幾個步驟：

  1. 檢查當前限制：
    你可以使用 ulimit -n 命令來查看當前 shell 會話中打開文件的數量限制。然而，Nginx 進程的限制可能由系統或用戶級別的限制設置，而不是由 shell 會話設置。

    爲了查看 Nginx 進程的實際限制，你可以查看 /proc/[nginx_pid]/limits 目錄中的文件，其中 [nginx_pid] 是 Nginx 主進程的 PID。或者，你可以使用 cat /proc/[nginx_pid]/limits | grep 'Max open files' 命令。

  2. 增加用戶級別的限制：
    如果你確定問題是用戶級別的限制，你可以修改 /etc/security/limits.conf 文件，添加或修改類似下面的行來增加打開文件的限制：

    複製代碼
      * soft nofile 4096
      * hard nofile 65535

    或者，只爲運行 Nginx 的用戶（如 www-data）設置限制：

    複製代碼
      www-data soft nofile 4096
      www-data hard nofile 65535

    注意：修改這些限制後，需要重啓 Nginx 或重新登錄用戶才能生效。

  3. 增加系統級別的限制：
    如果你發現系統級別的限制也很低，你可能需要修改 /etc/sysctl.conf 文件（或相應的 sysctl 配置位置），增加 fs.file-max 的值。例如：

    複製代碼
      fs.file-max = 100000

    修改後，需要運行 sysctl -p 或重啓系統來應用新的設置。

  4. 優化 Nginx 配置：
    確保你的 Nginx 配置中沒有導致打開過多文件的設置。例如，避免不必要的日誌記錄、優化緩存設置等。

  5. 檢查文件描述符泄漏：
    如果 Nginx 進程持續打開新的文件描述符而沒有關閉它們，這可能是資源泄漏的跡象。使用工具如 lsoft 或 strace 可以幫助你診斷這種情況。

  6. 重啓 Nginx：
    在修改限制或修復潛在的問題後，重啓 Nginx 以確保更改生效。

  7. 監控和日誌：
    監控 Nginx 進程的文件描述符使用情況，並定期檢查日誌文件以獲取可能的線索。

請注意，在修改系統或用戶級別的限制之前，最好先了解你的系統環境和需求，以避免意外的問題。如果你不確定如何操作，最好諮詢系統管理員或有經驗的開發人員。

 

 

查看進程最大打開文件個數

 

要查看Linux系統中進程的最大打開文件個數限制，你可以使用ulimit命令（針對當前shell會話）或查看/proc文件系統下的特定進程信息。但是，ulimit通常顯示的是當前shell會話的限制，而不是特定進程的限制。

要查看特定進程（例如Nginx的主進程）的最大打開文件數限制，你可以直接讀取/proc/[pid]/limits文件，其中[pid]是進程的PID。但是，這個文件的內容可能不太容易直接讀取，因爲它包含了多個字段和限制。

一個更簡單的方法是使用cat命令結合grep來提取與打開文件數（nofile）相關的行：

bash複製代碼
  cat /proc/[pid]/limits | grep 'Max open files'

將[pid]替換爲你要查詢的進程的PID。這將顯示類似以下內容的輸出：

複製代碼
  Max open files 1024 4096 files

這裏，1024是軟限制（soft limit），表示進程在達到這個限制時會收到警告，但可以繼續運行；4096是硬限制（hard limit），表示進程不能打開超過這個數量的文件。

如果你只是想快速查看某個用戶的默認打開文件數限制（這通常也是新進程的默認限制），你可以使用ulimit -n命令（在用戶的shell中執行）：

bash複製代碼
  ulimit -n

這將顯示當前shell會話的打開文件數軟限制。請注意，這不一定反映Nginx或其他進程的實際限制，除非這些進程在當前shell會話中啓動。

最後，如果你想要修改這些限制，你可能需要編輯/etc/security/limits.conf文件（對於用戶級別的限制）或使用sysctl命令修改系統級別的fs.file-max參數（這控制整個系統的文件描述符數量上限）。但是，在修改這些設置之前，請確保你瞭解它們的影響，並在可能的情況下先在測試環境中進行驗證。

 

 

ulimit生效命令

在Linux系統中，ulimit 命令用於設置或報告當前shell會話的資源限制。這些限制包括打開文件的最大數量、進程可以創建的最大數量、棧大小、CPU時間等。然而，ulimit 的設置僅對當前shell會話及其子進程有效，不會影響已經運行的進程或其他用戶的shell會話。

查看當前限制

要查看當前shell會話的打開文件數限制，可以使用：

bash複製代碼
  ulimit -n

設置資源限制

要設置打開文件的最大數量限制（例如，設置爲4096），可以使用：

bash複製代碼
  ulimit -n 4096

這將對當前shell會話及其所有後續啓動的子進程生效。但是，它不會影響已經運行的進程或其他用戶的shell會話。

持久化ulimit設置

由於ulimit的設置僅對當前shell會話有效，因此如果你希望在系統啓動時或在新的shell會話中自動應用這些設置，你需要將它們添加到用戶的shell配置文件（如.bashrc、.bash_profile、.zshrc等）中。

例如，在Bash shell中，你可以將ulimit命令添加到~/.bashrc文件的末尾：

bash複製代碼
  echo 'ulimit -n 4096' >> ~/.bashrc

然後，爲了使更改生效，你需要重新加載.bashrc文件或啓動一個新的shell會話：

bash複製代碼
  source ~/.bashrc

或者，你可以簡單地關閉並重新打開終端。

注意事項

  • 修改ulimit設置可能會影響程序的正常運行，特別是如果設置的限制低於程序所需的值。因此，在修改這些設置之前，請確保你瞭解它們的影響。
  • 如果你想要修改系統級別的資源限制（例如，fs.file-max），你需要使用sysctl命令或編輯相應的系統配置文件（如/etc/sysctl.conf），並可能需要重啓系統或重新加載內核參數才能使更改生效。
  • 對於Nginx等長時間運行的服務，通常建議在系統啓動腳本或init.d腳本中設置適當的資源限制，以確保服務在啓動時具有正確的限制。這可以通過在啓動腳本中添加ulimit命令或使用其他機制（如systemd的LimitNOFILE指令）來實現。

 

 

修改nginx進程 Max open files

 

要修改Nginx進程的最大打開文件數（Max open files），你需要做的是調整Nginx運行用戶的文件描述符（file descriptor）限制。這通常涉及到修改系統級別的設置和用戶級別的限制。

1. 修改系統級別的文件描述符限制

首先，你可能需要修改系統級別的文件描述符限制，這可以通過編輯/etc/sysctl.conf文件來實現。在文件中添加或修改以下行：

bash複製代碼
  fs.file-max = 100000 # 這是一個例子，你可以根據需要調整這個值

然後，運行sysctl -p來使更改生效，或者重啓系統。

2. 修改用戶級別的文件描述符限制

Nginx通常以特定的用戶身份運行（如nginx、www-data等）。你需要爲這個用戶設置文件描述符的限制。這可以通過修改/etc/security/limits.conf文件來實現。在文件中添加或修改類似以下行：

bash複製代碼
  * soft nofile 4096
  * hard nofile 65535
  # 或者爲特定的Nginx用戶設置
  nginx soft nofile 4096
  nginx hard nofile 65535

這裏的*表示所有用戶，但你也可以爲特定的Nginx用戶（如nginx）設置限制。soft是警告限制，當達到這個限制時，系統會給用戶一個警告，但仍然允許其繼續運行。hard是硬限制，當達到這個限制時，系統將不允許用戶打開更多的文件。

3. 使用systemd管理Nginx服務

如果你的系統使用systemd來管理Nginx服務，你也可以在Nginx的systemd服務單元文件中設置資源限制。編輯Nginx的service文件（通常位於/etc/systemd/system/或/lib/systemd/system/目錄下），添加或修改LimitNOFILE選項：

ini複製代碼
  [Service]
  User=nginx
  Group=nginx
  LimitNOFILE=65535
  ExecStart=/usr/sbin/nginx -g 'daemon off;'
  ...

修改後，重新加載systemd配置並重啓Nginx服務：

bash複製代碼
  sudo systemctl daemon-reload
  sudo systemctl restart nginx

4. 驗證設置

要驗證設置是否生效，你可以檢查Nginx進程的/proc/[pid]/limits文件（將[pid]替換爲Nginx主進程的PID），或者運行以下命令來查看Nginx用戶的限制：

bash複製代碼
  sudo -u nginx bash -c 'ulimit -n'

如果輸出與你在limits.conf或systemd服務單元文件中設置的限制相匹配，那麼設置就已經生效了。

 

 

 

worker_rlimit_nofile 51200

 

在Nginx的配置文件中，worker_rlimit_nofile 指令用於設置工作進程（worker process）可以打開的最大文件描述符數量。這個設置對於Nginx服務器來說非常重要，因爲它直接關聯到Nginx能夠處理的併發連接數。

在Nginx的配置文件（通常是nginx.conf或者包含在nginx.conf中的某個include文件）中，你可以設置 worker_rlimit_nofile 的值，例如：

nginx複製代碼
  worker_rlimit_nofile 51200;

這條指令告訴Nginx，每個工作進程最多可以打開51200個文件描述符。

請注意，worker_rlimit_nofile 的設置值應該根據你的系統資源和Nginx的使用情況進行調整。如果你設置的值太高，可能會導致系統資源耗盡；如果設置得太低，可能會限制Nginx的性能。

此外，你還應該確保系統級別的限制（通過sysctl和/etc/sysctl.conf設置）和用戶級別的限制（通過/etc/security/limits.conf設置）允許Nginx達到這個值。如果系統或用戶級別的限制低於你在Nginx配置中設置的值，那麼Nginx將無法使用超過這些限制的文件描述符數量。

最後，在修改這些設置後，你需要重新加載或重啓Nginx以使更改生效。如果你使用的是systemd管理Nginx服務，可以使用以下命令來重新加載Nginx配置：

bash複製代碼
  sudo systemctl reload nginx

或者重啓Nginx服務：

bash複製代碼
  sudo systemctl restart nginx

 

發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章

(原創) odoo各版本對視圖中節點groups屬性的處理差別

1.14版(含14)視圖節點groups屬性的處理結果表現在可見性上(invisible)，如果當前用戶不在指定的角色中，則設置可見性標記invisible爲"1"         2.16版(含16)以後對視圖節點groups屬性的處理

yier 2024-06-08 14:35:45

lightdb hash index的性能和限制

　　除了btree外，lightdb是支持hash index的，但是總體來說支持的特性範圍均不如btree索引，比如parallel沒有btree索引智能，不支持=之外的操作，不支持bitmap index scan，不支持哈希唯一索引（

zhjh256 2024-06-08 14:32:04

pathlib and difflib

pathlib.Path("a.crt").write_text(a[0]) p.chmod(0o444) Path.cwd() p.write_bytes(b'Binary file contents') p.read_bytes()

root- 2024-06-08 14:31:34

利用WinSW將Nginx 作爲可正常啓動/停止的windows服務

下載winsw程序，Releases · winsw/winsw (github.com) 將下載的exe文件放置到nginx.exe的同級目錄，名字可以修改爲nginx-service.exe(也可不修改) 新建txt文本文檔，並將其名

漫漫人生路總會錯幾步 2024-06-08 14:30:54

純CSS+單個div實現抖音LOGO

純CSS+單個div就能繪製抖音LOGO 關鍵點： 主要藉助了兩個僞元素實現了整體結構，藉助了 drop-shadow 生成一層整體陰影 drop-shadow 只能是單層陰影，所以另一層陰影需要多嘗試 contrast(150%) br

劉漢貴 2024-06-08 14:30:14

告別Word，用Python打造你的專業簡歷！

今天給大家介紹下一個在純 python 中構建簡歷的實用工具，工具的連接地址https://github.com/koek67/resume-builder/blob/main/readme.md 用法介紹 要求 Python 3.7 或更

十月狐狸 2024-06-08 14:24:54

一款.NET開源、免費、實用的多功能原神工具箱（改善桌面端玩家的遊戲體驗）

前言 今天大姚給大家分享一款.NET開源（MIT License）、免費、實用的多功能原神工具箱，旨在改善桌面端玩家的遊戲體驗：胡桃工具箱。 工具箱介紹 胡桃工具箱是一款.NET開源（MIT License）、免費、實用的多功能原神工具箱

追逐時光 2024-06-08 14:24:33

輻射3刷藥

去megaton裏面的屍鬼.那裏買藥, 把破爛賣給他. 然後傳送到其他地圖, 再傳送回來, 他就又有錢和新藥了.繼續賣破爛, 買藥.刷幾次就夠了.

張博的博客 2024-06-08 14:22:03

重新研究go的併發模型.

go裏面可以實現很多併發模型的優雅解決方案. 總結起來. package main import ( "fmt" "time" ) var bufChan chan int = make(chan int, 1000) var

張博的博客 2024-06-08 14:22:03

Python 潮流週刊#54：ChatTTS 強大的文本生成語音模型

本週刊由 Python貓 出品，精心篩選國內外的 250+ 信息源，爲你挑選最值得分享的文章、教程、開源項目、軟件工具、播客和視頻、熱門話題等內容。願景：幫助所有讀者精進 Python 技術，並增長職業和副業的收入。 本期週刊分享了 12

豌豆花下貓 2024-06-08 14:21:23

kafka知識整理——部署

一、部署 （1）zk配置 修改zk配置文件config/zookeeper.properties，修改dataDir或端口 dataDir=/home/kafka/kafka3.7/data/zookeeper clientPort=218

鄭某 2024-06-08 14:16:43

Asp .Net Core 系列：詳解鑑權（身份驗證）以及實現 Cookie、JWT、自定義三種鑑權 （含源碼解析）

什麼是鑑權（身份驗證）？ https://learn.microsoft.com/zh-cn/aspnet/core/security/authentication/?view=aspnetcore-8.0 定義 鑑權，又稱身份驗證，是

IT技術派 2024-06-08 14:15:33

cdn到oss，根據用戶終端是手機和電腦等不同分別訪問兩套前端代碼

    使用規則引擎 其中一個配置了很多瀏覽器，另外一個配置匹配所有 ，這樣就能正常訪問。如果這兩個網站，有一個沒有使用規則引擎，那麼就會兩個網站都匹配上，然後第四條規則目標path和第一條的會拼接起來作爲oss的key,肯定不存在，所以

馬昌偉 2024-06-08 14:14:22

Codeforces Round 950 (Div. 3)G. Yasya and the Mysterious Tree（字典樹處理區間異或值）

Problem - G - Codeforces 存個字典樹板子。 1 #include <bits/stdc++.h> 2 3 using i64 = long long; 4 5 constexpr int N

SnowLove 2024-06-08 14:10:12

Codeforces Round 949 (Div. 2)D. Turtle and Multiplication（歐拉路徑、線性篩、思維構造）

Problem - D - Codeforces    思路 補充官方正解，主要解釋一下爲什麼可以轉化爲求完全圖的歐拉路徑。題目要求構造的數的種數最少，相當於對於當前的m來說要儘可能構造出最長的序列長度，所以一定儘量要是完全圖。其次要求不

SnowLove 2024-06-08 14:10:12