此刻越來越多的站點(diǎn)開始用 Nginx ,("engine x") 是一個(gè)高機(jī)能的 HTTP 和反向署理處事器，也是一個(gè) IMAP/POP3/SMTP 署理處事器。 Nginx 是由 Igor Sysoev 為俄羅斯會(huì)見量第二的 Rambler.ru 站點(diǎn)開拓的，它已經(jīng)在該站點(diǎn)運(yùn)行高出兩年半了。Igor 將源代碼以類BSD許可證的形式宣布。

在高并發(fā)毗連的環(huán)境下，Nginx是Apache處事器不錯(cuò)的替代品。Nginx同時(shí)也可以作為7層負(fù)載平衡處事器來利用。按照測(cè)試功效，Nginx 0.6.31 + PHP 5.2.6 (FastCGI) 可以遭受3萬(wàn)以上的并發(fā)毗連數(shù)，相當(dāng)于同等情況下Apache的10倍。

但許多人用 Nginx 的時(shí)候城市呈現(xiàn) 500 錯(cuò)誤，美國(guó)服務(wù)器租用 美國(guó)站群服務(wù)器，按照我利用的環(huán)境來看，很大一部門原因是 因?yàn)槲募蜷_句柄太小有關(guān)。

在linux 下 利用這個(gè)呼吁增加歷程打開的文件句柄。

ulimit -SHn 51200

默認(rèn)只用1000 當(dāng)鏈接數(shù)小的時(shí)候看不出來，利用這種處理懲罰要領(lǐng)可以有效防備500錯(cuò)誤呈現(xiàn)。

本日會(huì)見網(wǎng)站的時(shí)候,偶然會(huì)趕上500 Internal Server Error的錯(cuò)誤提示頁(yè)面.

查了相關(guān)資料認(rèn)為是會(huì)見過大,系統(tǒng)內(nèi)核歷程受限才呈現(xiàn)的.

謎底如下:

$ ulimit -n

 11095

 措施限制只能打開11095個(gè)文件,ulimit呼吁是配置當(dāng)前用戶一個(gè)歷程可擁有的文件描寫符的數(shù)量.

看來是模仿的并發(fā)數(shù)太多了，需要調(diào)解一下nginx.conf的并發(fā)配置數(shù)，（我的設(shè)置主機(jī)的內(nèi)存2G,CPU為2.8G,）

vi /etc/nginx/nginx.conf

 events {

    worker_connections 1024;

 }

 調(diào)解為

 events {

    worker_connections 10240;

 }照舊會(huì)呈現(xiàn)上面問題，利用

 [[email protected] nginx]# cat /proc/sys/fs/file-max

 8192

 文件系統(tǒng)最大可打開文件數(shù)

 [[email protected] nginx]# ulimit -n

 1024

 措施限制只能打開1024個(gè)文件

 利用[[email protected] nginx]# ulimit -n 8192調(diào)解一下

 可能永久調(diào)解打開文件數(shù) 可在啟動(dòng)文件/etc/rc.d/rc.local末端添加（在/etc/sysctl.conf末端添加fs.file-max=8192）

ulimit -n 8192

調(diào)解CentOS5文件打開數(shù)

利用ulimit -a一下，發(fā)明OPEN FILES不能默認(rèn)高出1024，昨天的在舉辦壓力測(cè)試時(shí)，呈現(xiàn)500錯(cuò)誤，詳細(xì)請(qǐng)查察

nginx呈現(xiàn) 500 Internal Server Error

 早上起來看一下，發(fā)明本來是通過如下方法調(diào)解

要領(lǐng)1 （永久調(diào)解）

vi /etc/security/limits.conf

在文件末加上：

 *                soft  nofile          8192

 *                hard  nofile          20480

同時(shí)vi /etc/sysctl.conf末端添加

fs.file-max=8192

從頭啟動(dòng)，在利用ulimit -n查察的數(shù)已經(jīng)是8192

要領(lǐng)2 （姑且用）

直接在終端輸入 ulimit -n 8192 按回車就ok了