[code.nginx] Nginx服务器高级配置

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

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

#/sbin/sysctl -p

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

net.core.netdev_max_backlog = 262144

** 2.net.core.somaxconn参数 **
该参数用于调节系统同时发起的TCP连接数,一般默认值为128。在客户端存在高并发请求的情况下,在默认值较小,可能导致链接超时或者重传问题,我们可以根据实际需要结合并发请求数来调节此值。

net.core.somaxconn = 262144

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

net.ipv4.tcp_max_orphans = 262144

** 4.net.ipv4.tcp_max_syn_backlog参数 **
该参数用于记录尚未收到客户端确认信息的连接请求的最大值。对于拥有128MB内存的系统而言,此参数的默认值是1024,对小内存的系统则是128。一般在系统内存比较充足的情况下,可以增加这个参数的赋值:

net.ipv4.tcp_max_syn_backlog = 262144

** 5.net.ipv4.tcp_timestamps参数 **
该参数用于设置时间戳,这可以避免序列号的卷绕。在一个1Gb/s的链路上,遇到以前用过的序列号的概率很大。当此值赋值为0时,禁用对于TCP时间戳的支持。在默认情况下,TCP协议会让内核接受这种“异常”的数据包。针对Nginx服务器来说,建议将其关闭:

net.ipv4.tcp_timestamps = 0

** 6.net.ipv4.tcp_synack_retries参数 **
该参数用于设置内核放弃TCP连接之前向客户端发送SYN+ACK包的数量。为了建立对端的连接服务,服务器和客户端需要进行三次握手,第二次握手期间,内核需要发送SYN并附带一个回应前一个SYN的ACK,这个参数主要影响这个进程,一般赋值为1,即内核放弃连接之前发送一次SYN+ACK包,可以设置其为:

net.ipv4.tcp_synack_retries = 1

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

net.ipv4.tcp_syn_retries = 1

针对CPU的Nginx配置优化的2个指令

在Nginx配置文件中,有这样两个指令:worker_processes和worker_cpu_affinity,它们可以针对多核CPU进行配置优化。
** 1.worker_processes指令 **
worker_processes指令用来设置Nginx服务的进程数。官方文档建议此指令一般设置为1即可,赋值太多会影响系统的IO效率,降低Nginx服务器的性能。为了让多核CPU能够很好的并行处理任务,我们可以将worker_processes指令的赋值适当的增大一些,最好是赋值为机器CPU的倍数。当然,这个值并不是越大越好,Nginx进程太多可能增加主进程调度负担,也可能影响系统的IO效率。针对双核CPU,建议设置为2或
4。如果是四核CPU,设置为:

worker_processes 4;

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

** 2. worker_cpu_affinity指令 **
worker_cpu_affinity指令用来为每个进程分配CPU的工作内核。这个指令用来为每个进程分配CPU的工作内核。这个指令的设置方法有些麻烦。
如下图所示:


worker_cpu_affinity指令

worker_cpu_affinity指令的值是由几组二进制值表示的。其中,每一组代表一个进程,每组中的每一位表示该进程使用CPU的情况,1表示使用,0表示不使用。注意,二进制位排列顺序和CPU的顺序是相反的。建议将不同的进程平均分配到不同的CPU运行内核上。
如果设置的Nginx服务的进程数为4,CPU为4核,因此会有四组值,并且每组有四位,所以,此指令的设置为:

worker_cpu_affinity 0001 0100 1000 0010;

四组二进制数值分别对应4个进程,第一个进程对应0001,表示使用第一个CPU内核。第二个进程对应0010,表示使用第二个CPU内核,以此类推。
如果将worker_processes指令的值赋值为8,即赋值为CPU内核个数的两倍,则worker_cpu_affinity指令的设置可以是:

worker_cup_affinity 001 0010 0100 1000 0001 0010 0100 1000;

如果一台机器的CPU是八核CPU,并且worker_processes指令的值赋值为8,那么worker_cpu_affinity指令的设置可以是:

worker_cpu_affinity 0000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;

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

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

keepalive_timeout 60 50;

该设置表示Nginx服务器与客户端连接保持活动的时间是60s,60s后服务器与客户端断开连接。使用Keep-Alive消息头保持与客户端某些浏览器(如Mozilla、Konqueror等)的连接时间为50s,50s后浏览器主动与服务器断开连接。

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

send_timeout 10s;

该设置表示Nginx服务器与客户端建立连接后,某次会话中服务器等待客户端响应超时10s,就会自动关闭连接。

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

#getconf PAGESIZE

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

client_header_buffer_size 4k;

** 4.multi_accept指令 **
该指令用于配置Nginx服务器是否尽可能多的接收客户端的网络连接请求,默认值为off。

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

本节涉及的指令与Nginx服务器的事件驱动模型密切相关。

  1. use指令
    use指令用于指定Nginx服务器使用的事件驱动模型。
  2. 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 accepting new connection on 0.0.0.:01

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

worker_connections 65535;

此指令的赋值与linux操作系统中进程可以打开的文件句柄数量有关系。按照以上设置修改此项赋值以后,Nginx服务器报以下错误:

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

究其原因,Linux系统中有一个系统指令open file resource limit,它设置了进程可以打开的文件句柄数量。worker_connections指令的赋值当然不能超过open 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就没问题了。

  1. worker_rlimit_sigpending指令
    该指令用于设置Linux 2.6.6-mm2版本之后Linux平台的事件信号队列长度上线。其语法结构为:
worker_rlimit_sigpending limit

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

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

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

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

其中,number为要设置的数量,默认值均为512.
使用kequeue_changes方式,可以设置与内核之间传递事件的数量。

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

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

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

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

rtsig_signo signo

默认的第一个信号设置为SIGRTMIN+10。

提示
在Linux中可以使用一下命令查看系统支持的SIGRTMIN有哪些。

kill -l | grep SIGRTMIN

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

rtsig_overflow_* number

其中,number是要设定的值。
rtsig_overflow_events指令指定队列溢出时使用poll库处理的事件数,默认值为16。
rtsig_overflow_test指令设定poll库处理完第几件事件后将清空rtsig模型使用的信号队列,默认值为32。

rtsig_overflow_threshold指令指定rtsig模式使用的信号队列中的事件超过多少时就需要清空队列了。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 162,306评论 4 370
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 68,657评论 2 307
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 111,928评论 0 254
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 44,688评论 0 220
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 53,105评论 3 295
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 41,024评论 1 225
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 32,159评论 2 318
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,937评论 0 212
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,689评论 1 250
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,851评论 2 254
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,325评论 1 265
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,651评论 3 263
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,364评论 3 244
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,192评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,985评论 0 201
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 36,154评论 2 285
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,955评论 2 279

推荐阅读更多精彩内容