nginx服务器运行的实际环境和提供的功能千差万别,如何根据自己的工作经验和具体的使用环境为Nginx服务器配置恰当的指令,才是Nginx配置的核心内容.

    针对IPv4的内核７个参数的配置优化

    这里提及到的参数是和IPv4网络有关的Linux内核参数.我们可以将这些内核参数的值追加到Linux系统的/dev/sysctl.conf文件中,然后使用如下命令使其修改生效

/sbin/sysctl -p

    这些常用的参数包括以来这些.

    １.net.core.netdev_max_backlog参数

    参数net.core.netdev_max_backlog,表示当每个网络接口接收数据包的速率比内核处理这些包的速率快时,允许发送到队列的数据包的最大数目.一般默认值为１２８(可能不同的Linux系统该数值也不同).Nginx服务器中定义的NGX_LISTEN_BACKLOG默认为５１１.我们可以将它调整一下.

net.core.netdev_max_backlog = 262144

    2.net.core.somaxconn参数

    该参数用于调节系统同时发起的ＴＣＰ连接数,一般默认值为１２８.在客户端存在高并发请求的情况下,该默认值较小,可能导致链接超时或者重传问题,我们可以根据实际需要结合并发请求数来调节此值.笔者系统设置为:

net.core.somaxconn = 262144

    3.net.ipv4.tcp_max_orphans参数

    该参数用于设定系统中最多允许存在多少ＴＣＰ套接字不被关联到任何一个用户文件句柄上.如果超过这个数字,没有与用户文件句柄关联的TCP套接字将立即被复位,同时给出警告信息.这个限制只是为了防止简单的Dos(Denial of Service,拒绝服务)攻击.一般在系统内存比较充足的情况下,可以增大这个参数的赋值,如

net.ipv4.tcp_max_orphans = 262144

    4.net.ipv4.tcp_max_syn_backlog参数

    该参数用于记录尚未收到客户端确认信息的连接请求的最大值.对于拥有１２８ＭＢ内存的系统而言,该参数的默认值为１０２４,对小内存的系统则是１２８.一般在系统内存比较充足的情况下,可以视情况加大这个参数的赋值.

net.ipv4.tcp_max_syn_backlog = 262144

    5.net.ipv4.tcp_timestamps参数

    该参数用于设置时间戳,这可以避免序列号的缠绕.在一个１Ｇb/s的链路上,遇见以前用过的序列号的概率很大.当此值赋值为０时,禁用对于ＴＣＰ时间戳的支持.在默认的情况下,ＴＣＰ协议会让内核接受这种'异常'的数据包.针对ＮＧＩＮＸ服务器来说,建议将其关闭:

net.ipv4.tcp_timestamps = 0

　6.net.ipv4.tcp_synack_retries参数

    该参数用于设置内核放弃ＴＣＰ连接之前向客户端发送SYN+ACK包的数据.为了建立对端的连接服务,服务器和客户端需要进行三次握手,第二次握手期间,内核需要发送ＳＹＮ并附带一个回应,前一个ＳＹＮ的ＡＣＫ,这个参数主要影响这个过程,一般赋值为１,即内核放弃连接之前发送一次ＳＹＮ+ＡＣＫ包,可以设置为:

net.ipv4.tcp_synack_retries = 1

    7.net.ipv4.tcp_syn_retries参数

    该参数的作用与上一个参数类似,设置内核放弃建立连接之前发送SYN包的数量,它的赋值和上一个参数一样即可.

net.ipv4.tcp_syn_retries = 1

    针对CPU的ＮＧＩＮＸ配置优化的２个指令

    处理器已经进入多核时代.多内核是指在一枚处理器中集成两个或多个完整的计算引擎,多核处理器是单枚芯片.一枚多核处理器上可以承载多枚内核,但只需要单一的处理器插槽就可以工作.同时,目前流行的操作系统都已经可以利用这样的资源,将每个执行内核作为分立的逻辑处理器,通过在多个执行内核之间划分任务,在特定的时钟周期内执行更多的任务,提高并行处理任务的能力.

    在ＮＧＩＮＸ配置文件中,有这样两个指令:worker_processes和worker_cpu_affinity,它们可以针对多核CPU进行配置优化.

    １.worker_processes指令

    worker_processes指令用来设置Nginx服务的进程数.官方文档建议此指令一般设置为１即可,赋值太多会影响系统的ＩＯ效率,降低ＮＧＩＮＸ服务器的性能.根据笔者经验,为了让多核ＣＰＵ能够很好的并行处理任务,我们可以将worker_processes指令的赋值适当的增大一些,最好是赋值为机器cpu的倍数.当然,这个值并不是越大越好.ＮＧＩＮＸ进程太多可能增加主进程高度负担,也可能影响系统的ＩＯ效率.针对双核ＣＰＵ,建议设置为２或４.笔者的机器为四核ＣＰＵ,设置为:

worker_processes 4;

    设置好worker_processes指令之后,就很有必要设置worker_cpu_affinity指令

    ２.worker_cpu_affinity指令

    worker_cpu_affinity指令用来为每个进程分配cpu的工作内核.这个指令的设置方法有些麻烦.笔者设置的nginx服务的进程数为４,ＣＰＵ是四核,因此会有四组值,并且每组有四位,所以,此指令的设置为

worker_cpu_affinity 0001 0100 1000 0010;

    四组二进制数值分别对应４个进程,第一个进程对应０００１,表示使用第一个ＣＰＵ内核;第二个进程对应０１００,表示使用第二个ＣＰＵ内核,以此类推.

    如果笔者将worker_processes指令的值赋值为８,即赋值为ＣＰＵ内核个数的两倍,则worker_cpu_affinity指令的设置可以是

worker_cpu_affinity 0001 0010 0100 1000 0001 0010 0100 1000;

    如果一台机器是８核ＣＰＵ,并且worker_processes指令值赋值为８,那么worker_cpu_affinity指令可以设置为:

worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;

    以上两例的具体含义不再赘述,相信大家通过前面的介绍能够明白.

    与网络连接相关的配置的４个指令

    １.keepalive_timeout指令

    该指令用于设置ＮＧＩＮＸ服务器与客户端保持连接的超时时间.

    这个指令支持两人个选项,中间用空格隔开.第一个选项指定客户端连接保持活动的超时时间,在这个时间之后,服务器会关闭此连接;第二个选项可选,其指定了使用Keep-Alive消息头保持活动的有效时间,如果不设置它,ＮＧＩＮＸ服务器不会向客户端发送Keep-Alive消息头以保持与客户端某些浏览器(如Mozilla,Konqueror等)的连接,超过设置的时间后,客户端就可以关闭连接,而不需要服务器关闭了.你可以根据自己的实际情况设置此值,建议从服务器的访问数量,处理速度以及网络状态方面考虑,下面是此指令的设置示例.

keepalive_timeout 60 50;

    该设置表示ＮＧＩＮＸ服务器与客户端连接保持活动的时间为60s,60s后服务器与客户端断开连接;使用Keep_Alive消息头保持与客户端某些浏览器(如Mozilla,Konqueror等)的连接时间为５０Ｓ,５０s后浏览器主动与服务器断开连接.

    ２.send_timeout指令

    该指令用于设置Ｎginx服务器响应客户端的超时时间,这个超时时间仅针对两人个客户端和服务器之间建立连接后,某次活动之间的时间.如果这个时间后客户端没有任何活动,ＮＧＩＮＸ服务器将会关闭连接.此指令的设置需要考虑服务器访问数量和网络状况等方面.下面是此指令的设置示例.

send_timeout 10s;

    该设置表示ＮＧＩＮＸ服务器与客户端建立连接后,某次会话中服务器等待客户端响应超过１０s,就会自动关闭连接.

    3.client_header_buffer_size命令

    该指令用于设置nginx服务器允许的客户端请求头部的缓冲区大小.默认为1kb.此指令的赋值可以根据系统分页大小来设置.分页大小可以用以来命令取得

getconf PAGESIZE

    有过ＮＧＩＮＸ服务器工作经验的朋友可能遇到过nginx服务器返回４００错误的情况.查找nginx服务器的４００错误原因比较困难,因为此错误并不是每次都会出现,出现错误的时候,通常在浏览器和日志里也看不到任何有关提示信息.根据实际的经验来看,有很大一部分情况是客户端的请求头部过大造成的.请求头部过大,通常是客户端的ＣＯＯＫＩＥ中写入了较大的值引起的.于是适当的增大此指令的赋值,允许ＮＧＩＮＸ服务器接收较大的请求头部,可以改善服务器对客户端的支持参力.笔者一般将此指令赋值为4kb大小,即:

    client_header_buffer_size 4k;

    与事件驱动模型相关的配置的８个指令

    １.use指令

    use指令用于指定nginx服务器使用的事件驱动模型.

    ２.worker_connections指令

    该指令用于设置nginx服务器的每个工作进程允许同时连接客户端的最大数量,语法为:

    worker_connections_number

    其中,number为设置的最大数量.结合worker_processes指令,我们可以计算出Nginx服务器允许时间连接的客户端最大数量Client = worker_processes * worker_connections/2

    在使用Nginx服务器的过程中,笔者曾经遇到过无法访问Nginx服务器的情况,查看日志发现一直在报如下错误

[alert] 24082#0:1024 worker_connections is not enough while acceptiong new connection on 0.0.0.0:81

    根据报错信息,推测可能是nginx服务器的最大访问连接数设置小了.此指令设置的就是nginx服务器能接受的最大访问量,其中包括前端用户连接也包括其它连接,这个值在理论上等于此指令的值与它允许开启的工作进程最大数的乘积.此指令一般设置为６５５３５:

woker_connections 65535;

    此指令的赋值与linux操作系统中的进程可以打开的文件句柄数量有关系.笔者曾经遇到过这样的情况,按照以上设置修改了此项赋值以后,ＮＧＩＮＸ服务器报如下错误

[warn]: 8192 worker_connections are more than open file resource limit :1024

    究其原因,linux系统中有一个系统指令 open file resource limit,它设置了进程可以打开的文件句柄ovtj.worker_connections指令的赋值当然不能超过oepn file resource limit 的赋值.可以使用以下命令查看在你的linux系统中open file resource limit 指令的值

cat /proc/sys/fs/file-max

    可以通过以下命令将open file resource limit 指令的值设为2390251:

# echo "2390251" > /proc/sys/fs/file-max; sysctl -p

    这样,Nginx的worker_connections 指令赋值为65535就没问题了.

    ３.worker_rlimit_sigpending指令

    该指令用于设置Linux 2.606-mm2版本之后linux平台的事件信号队列长度上限.其语法结构为:

    worker_rlimit_sigpending limit

    其中,limit为Linux平台事件信号队列的长度上限值.

    该指令主要影响事件驱动模型中的rtsig模型可以保存的最大信号数.Nginx服务器的每一个工作进程有自己的事件信号队列用于暂存客户端请求发生信号,如果超过长度上限,nginx服务器自动转用poll模型处理未处理的客户端请求.为了保证nginx服务器对客户端请求的高效处理,请大家根据实际的客户端并发请求数量和服务器运行环境的处理能力设定该值.设置示例为:

    worker_rlimit_sigpending 1024

    4.devpoll_changes和devpoll_events指令

    这两人个指令用于设置在/dev/poll事件驱动模式下Nginx服务器可以与内核之间传递事件的数量,前者设置传递给内核的事件数量,后者设置从内核获取的事件数量,语法结构为:

    devpoll_changes number
    devpoll_events number

    其中,number为要设置的数量,默认值均为32

    5.kqueue_changes 和 kqueue_events指令

    这两人个指令用于设置在kqueue事件驱动模式下nginx服务器可以与内核之间传递事件的数量,前者设置传递给内核的事件数量,后者设置从内核获取的事件数量,其语法结构为:

    kqueue_changes number
    kqueue_events number

    其中,number为要设置的数量,默认值均为５１２

    使用kequeue_changes方式,可以设置与内核之间传递事件的数量.

    ６.epoll_events指令

    该指令用于设置在epoll事件驱动模式下nginx服务器可以与内核之间传递事件的数量,其语法结构为

    epoll_changes number

    其中,number为要设置的数量,默认值均为512

    注意:与其它事件驱动模型不同,在epoll事件驱动模式下nginx服务器向内核传递事件的数量和从内核传递的事件数量是相等的,因此没有类似epoll_changes这样的指令.

    ７.rtsig_signo指令

    该指令用于设置rtsig模式使用的两个信号中的第一个,第二个信号是在第一个信号的编号上加１,语法为

    rtsig_signo signo

    默认的第一个信号设置为SIGRTMIN+10,查看系统支持的ＳＩＧＲＴＭＩＮ命令为

    kill -l | grep SIGRTMIN

    ８.rtsig_overflow_*指令

    该指令代表三个具体的指令,分别为rtsig_overflow_events指令,rtsig_overflow_test指令和rtsig_overflow_threshold指令.这些指令用来控制当rtsig模式中信号队列溢出时nginx服务器的处理方式,它们的语法结构为:

    rtsig_overflow_* number

    其中,number是要设定的值.

    rtsig_overflow_events指令指定队列溢出时使用poll库处理事件数,默认值为１６.

    rtsig_overflow_test指令指定poll库处理完第几件事件后将清空rtsig模型使用的信号队列,默认值为３２

    rtsig_overflow_threshold指令指定rtsig模式使用的信号队列中的事件超过多少时就需要清空队列了.该指令只对linux2.4.x及以下的版本有效.在这些版本中包含两人个参数,分别是proc/sys/kernel/ rtsig-nr和/proc/sys/kernel/rtsig-max/rtsig_overflow_threshold,后者就是该指令设定的值.当nginx服务器检测到前者大于后者时,将清空队列.该指令默认值为１０,代表rtsig-max的1/10.

• Running
• 站点索引

• 申请