一、訪問Nginx時，報錯："accept() failed (24: Too many open files)"
原因時：nginx的連接數超過了系統設定的最大值造成的.
處理辦法如下:
[root@kvm-server nginx]# ulimit -n 1024 [root@kvm-server nginx]# ulimit -n 655360 #把打開文件數設置足夠大，這是臨時修改方案 [root@kvm-server nginx]# ulimit -n 655360 同時修改nginx.conf文件,添加下面內容，然后重啟nginx worker_rlimit_nofile 655350； 這樣就可以解決Nginx連接過多的問題，Nginx就可以支持高並發。 另外， ulimit -n 還會影響到mysql 的並發連接數。提高文件連接數設置，也能提高mysql並發。 注意： 用ulimit -n 655360 修改只對當前的shell有效，退出后失效。所以，需要永久性修改 永久生效方法： 修改/etc/security/limits.conf，在文件底部添加： * soft nofile 655360 * hard nofile 655360 星號代表全局， soft為軟件，hard為硬件，nofile為這里指可打開文件數。 另外，要使limits.conf文件配置生效，必須要確保 pam_limits.so 文件被加入到啟動文件中。 查看 /etc/pam.d/login 文件中有： session required /lib/security/pam_limits.so 這樣，問題就迎刃而解了！
ulimit : 設置最大進程數和最大文件打開數, 這個一般是系統優化的必要手段.
1) 臨時修改 為了優化linux性能，可能需要修改這個最大值。臨時修改的話ulimit -n 655360就可以了，重啟后失效。 [root@localhost ~]# ulimit -n 1024 [root@localhost ~]# ulimit -n 655360 [root@localhost ~]# ulimit -n 655360 2) 永久修改 修改/etc/security/limits.conf文件, 在文件末尾添加 [root@localhost ~]# vim /etc/security/limits.conf * soft nofile 655360 * hard nofile 655360 * soft nproc 655360 * hard nproc 655360 ============================= 上面配置內容中: * 代表針對所有用戶 noproc 是代表最大進程數 nofile 是代表最大文件打開數 如上修改后重啟服務或服務器,如果發現沒更改過來, 還需要修改下面梁文文件 在/etc/security/limits.d/90-nproc.conf文件末尾添加 [root@localhost ~]# vim /etc/security/limits.d/90-nproc.conf * soft nproc 655360 * hard nproc 655360 在/etc/security/limits.d/def.conf文件末尾添加 [root@localhost ~]# vim /etc/security/limits.d/def.conf * soft nofile 655360 * hard nofile 655360 然后重啟后生效
二、普通用戶登錄系統，報錯:"-bash: ulimit: open files: cannot modify limit: Operation not permitted"
[root@locahost ~]# ssh -p22 work@172.16.60.20 Authorized only. All activity will be monitored and reported Last login: Wed Dec 18 19:19:59 2019 from 172.16.60.11 -bash: ulimit: open files: cannot modify limit: Operation not permitted -bash: ulimit: data seg size: cannot modify limit: Operation not permitted -bash: ulimit: max memory size: cannot modify limit: Operation not permitted -bash-4.1$ -bash-4.1$ ulimit -n 1024 登錄172.16.60.20機器的root用戶查看 [root@server-20 ~]# ulimit -n 32726 [root@server-20 ~]# cat /etc/security/limits.conf ........ # End of file work soft nproc 8192 work hard nproc 8192 work soft nofile 16384 work hard nofile 32768 以上work普通用戶登錄系統后，出現"-bash: ulimit: open files: cannot modify limit: Operation not permitted."報錯， 並且work普通用戶下查看ulimit數值是默認的1024，設置的ulimit值（32678）並沒有生效！ 解決辦法： 修改sshd_config文件，將UseLogin默認的no改為yes [root@server-20 ~]# /etc/ssh/sshd_config ....... UseLogin yes 然后重啟sshd服務 [root@server-20 ~]# service sshd restart 再次登錄172.16.60.20的work用戶，就不會出現上面的報錯信息了 [root@locahost ~]# ssh -p22 work@172.16.60.20 Authorized only. All activity will be monitored and reported Last login: Wed Dec 18 19:54:47 2019 from 172.20.20.161 -bash-4.1$ -bash-4.1$ ulimit -n 32768 ============================================================================================= UseLogin 指令 表示是否在交互式會話的登錄過程中使用 login(1) 。默認值是"no"。 如果開啟此UseLogin指令，那么 X11Forwarding 將會被禁止，因為 login(1) 不知道如何處理 xauth(1) cookies 。 需要注意的是，login(1) 是禁止用於遠程執行命令的。如果指定了 UsePrivilegeSeparation ，那么它將在認證完成后被禁用。
三、重啟Nginx時, 出現報錯提示： "could not build the server_names_hash, you should increase server_names_hash_bucket_size: 64"
解釋說明: 保存服務器名字的hash表是由指令 server_names_hash_max_size 和 server_names_hash_bucket_size所控制的。參數hash bucket size總是等於hash表的大小，並且是一路處理器緩存大小的倍數。在減少了在內存中的存取次數后，使在處理器中加速查找hash表鍵值成為可能。如果 hash bucket size等於一路處理器緩存的大小，那么在查找鍵的時候，最壞的情況下在內存中查找的次數為2。第一次是確定存儲單元的地址，第二次是在存儲單元中查找鍵值。因此，如果Nginx給出需要增大 hash max size 或 hash bucket size的提示，那么首要的是增大前一個參數的大小.
解決辦法：在nginx配置文件nginx.conf里的http{}段增加一行配置"server_names_hash_bucket_size 64;" ，如果64還不夠，那么就按32的倍數往上加,比如128或256或512。
四、Nginx出現500 Internal Server Error 錯誤的解決方案
500（服務器內部錯誤） 服務器遇到錯誤，無法完成請求。 501（尚未實施） 服務器不具備完成請求的功能。例如，當服務器無法識別請求方法時，服務器可能會返回此代碼。 502（錯誤網關） 服務器作為網關或代理，從上游服務器收到了無效的響應。 503（服務不可用） 目前無法使用服務器（由於超載或進行停機維護）。通常，這只是一種暫時的狀態。 504（網關超時） 服務器作為網關或代理，未及時從上游服務器接收請求。 505（HTTP 版本不受支持） 服務器不支持請求中所使用的 HTTP 協議版本。 Nginx 500錯誤（Internal Server Error 內部服務器錯誤）：500錯誤指的是服務器內部錯誤，也就是服務器遇到意外情況，而無法履行請求。遇到這種nginx出現500錯誤，大致原因如下： 1）磁盤空間是否不足？ ---------------------------------------- 使用"df -h" 查看硬盤空間是否滿了。清理硬盤空間就可以解決500錯誤。nginx如果開啟了access log，在不需要的情況下，最好關閉access log。access log會占用大量硬盤空間。 2) nginx配置文件錯誤？ ---------------------------------------- 這里不是指語法錯誤，nginx如果配置文件有語法錯誤，啟動的時候就會提示。當配置rewrite的時候，有些規則處理不當會出現500錯誤，請仔細檢查自己的rewrite規則。 如果配置文件里有些變量設置不當，也會出現500錯誤，比如引用了一個沒有值的變量。 3) 如果上面的問題都不存在，那么可能是模擬的並發數太多了（too many open files）？ ---------------------------------------- 需要調整一下nginx.conf的並發設置數 打開/etc/security/limits.conf文件，加上兩句： * soft nofile 65535 * hard nofile 65535 打開nginx.conf，修改 worker_rlimit_nofile 65535; 重新啟動nginx，重新載入設置 4）索引節點(inode)用滿導致？ ---------------------------------------- 使用"df -i"命令查看系統的inode是否爆滿，如果使用達到100%，就釋放inode空間。 5）數據庫問題導致？ ---------------------------------------- 如果上面情況都不存在，可以查看是否是因為數據庫問題，比如數據庫訪問不到。 6）如果按上述方法仍然解決不了問題，就可能是配置或是程序有錯誤了。 ---------------------------------------- 查看nginx的錯誤日志，找到可能的原因。 比如提示某些兒PHP擴展沒有安裝，則去php.ini中打開對應該的擴展或是安裝對應該的擴展，重啟nginx和php-fpm，再次刷新頁面。 如果數據庫連接有問題，也可能會出現500錯誤，不過日志中一定會體現的 在日志中提示相應的數據庫連接有問題了，就要去查看數據庫連接是否正確。根據日志，修改對應該的文件，數據庫問題解決后，頁面即恢復正常。