|
現(xiàn)在越來越多的站點開始用 Nginx ,("engine x") 是一個高性能的 HTTP 和反向代理服務(wù)器，也是一個 IMAP/POP3/SMTP 代理服務(wù)器。 Nginx 是由 Igor Sysoev 為俄羅斯訪問量第二的 Rambler.ru 站點開發(fā)的，它已經(jīng)在該站點運行超過兩年半了。Igor 將源代碼以類BSD許可證的形式發(fā)布。 復(fù)制代碼 代碼如下: vi /etc/nginx/nginx.conf events { worker_connections 1024; } 調(diào)整為 復(fù)制代碼 代碼如下: events { worker_connections 10240; } 還是會出現(xiàn)上面問題，使用 [root@qimutian nginx]# cat /proc/sys/fs/file-max 8192 文件系統(tǒng)最大可打開文件數(shù) [root@qimutian nginx]# ulimit -n 1024 程序限制只能打開1024個文件 使用[root@qimutian nginx]# ulimit -n 8192調(diào)整一下 或者永久調(diào)整打開文件數(shù) 可在啟動文件/etc/rc.d/rc.local末尾添加（在/etc/sysctl.conf末尾添加fs.file-max=8192） ulimit -n 8192 調(diào)整CentOS5文件打開數(shù) 使用ulimit -a一下，發(fā)現(xiàn)OPEN FILES不能默認超過1024，昨天的在進行壓力測試時，出現(xiàn)500錯誤，具體請查看 nginx出現(xiàn) 500 Internal Server Error 早上起來看一下，發(fā)現(xiàn)原來是通過如下方式調(diào)整 方法1 （永久調(diào)整） vi /etc/security/limits.conf 在文件末加上： * soft nofile 8192 * hard nofile 20480 同時vi /etc/sysctl.conf末尾添加 fs.file-max=8192 重新啟動，在使用ulimit -n查看的數(shù)已經(jīng)是8192 方法2 （臨時用） 直接在終端輸入 ulimit -n 8192 按回車就ok了 500 Internal Server Error錯誤補充： 1、硬盤空間滿了 使用 df -k 查看硬盤空間是否滿了。清理硬盤空間就可以解決500錯誤。nginx如果開啟了access log，在不需要的情況下，最好關(guān)閉access log。access log會占用大量硬盤空間。 2、nginx配置文件錯誤 這里不是指語法錯誤，nginx如果配置文件有語法錯誤，啟動的時候就會提示。當(dāng)配置rewrite的時候，有些規(guī)則處理不當(dāng)會出現(xiàn)500錯誤，請仔細檢查自己的rewrite規(guī)則。如果配置文件里有些變量設(shè)置不當(dāng)，也會出現(xiàn)500錯誤，比如引用了一個沒有值的變量。 3、如果上面的問題都不存在可能是模擬的并發(fā)數(shù)太多了，需要調(diào)整一下nginx.conf的并發(fā)設(shè)置數(shù) 解決方法是： 1 打開/etc/security/limits.conf文件，加上兩句 復(fù)制代碼 代碼如下: * soft nofile 65535 * hard nofile 65535 2 打開/etc/nginx/nginx.conf 在worker_processes的下面增加一行 復(fù)制代碼 代碼如下: worker_rlimit_nofile 65535; 3 重新啟動nginx，重新載入設(shè)置 復(fù)制代碼 代碼如下: kill -9 `ps -ef | grep php | grep -v grep | awk '{print $2}'` /usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -C 100 -u www-data -f /usr/bin/php-cgi killall -HUP nginx 重啟后再看nginx的錯誤日志，也沒有發(fā)現(xiàn)500報錯的情況了。 4、有可能是數(shù)據(jù)庫問題我的在nginx日志php日志都沒有發(fā)現(xiàn)什么問題, 最后發(fā)現(xiàn)數(shù)據(jù)庫訪問不了,修正后問題解決. |
|
|
