浅谈Nginx性能调优

奇技指南

Web服务性能调优是一项系统工程,涵盖许多方面,其中某一环节做的好并不能够保证整体性能好;但是如果某个环节做的不好,那么整体性能必然不会好。

可以调优的配置有很多,绝大多数情况下我们不需要追求极致的性能,只需把短板补齐,使之能够满足我们需要就可以了。

Linux系统参数优化

下文中提到的一些配置,需要较新的Linux(2.6以上)内核才能够支持,笔者使用的CentOS 7.4,内核版本3.10,如果不满足需要的话,最好进行相应的升级,毕竟打补丁是件费力不讨好的事情。对于系统层面的调优,通常我们修改文件描述符限制、缓冲区队列长度以及临时端口数量就可以了。

文件描述符限制

由于每个TCP连接都要占用一个文件描述符,一旦文件描述符耗尽,新的连接到来就会返回“Too many open files”这样的错误,为了提高性能,我们需要对其进行修改:

系统层级的限制 编辑文件 /etc/sysctl.conf,添加如下内容:

fs.file-max = 10000000fs.nr_open = 10000000

用户层级的限制 编辑文件 /etc/security/limits.conf,添加以下内容:

*hard   nofile      1000000*soft   nofile      1000000

这里我们只要保证用户层级限制不大于系统层级限制就可以了,否则可能会出现无法通过SSH登录系统的问题。修改完毕执行如下命令:

$ sysctl -p

可以通过执行命令 ulimit -a查看是否修改成功。

TCP连接队列长度

编辑文件 /etc/sysctl.conf,添加如下内容:

# The length of the syn quenenet.ipv4.tcp_max_syn_backlog = 65535# The length of the tcp accept queuenet.core.somaxconn = 65535

其中tcp_max_syn_backlog用于指定半连接SYN队列长度,当新连接到来时,系统会检测半连接SYN队列,如果队列已满,则无法处理该SYN请求,并在 /proc/net/netstat中的 ListenOverflowsListenDrops中增加统计计数

somaxconn用于指定全连接ACCEPT队列长度,当该队列满了以后,客户端发送的ACK包将无法被正确处理,并返回错误"connection reset by peer"

Nginx则会记录一条error日志

"no live upstreams while connecting to upstreams"

如果出现以上错误,我们需要考虑增大这两项的配置。

临时端口

由于Nginx用作代理,每个到上游Web服务的TCP连接都要占用一个临时端口,因此我们需要修改ip_local_port_range参数 

修改 /etc/sysctl.conf文件,添加如下内容:

net.ipv4.ip_local_port_range = 1024 65535net.ipv4.ip_local_reserved_ports = 8080,8081,9000-9010

其中,参数 ip_local_reserved_ports用于指定保留端口,这是为了防止服务端口被占用而无法启动。

Nginx参数优化

Nginx参数优化主要围绕 nginx.conf这个配置文件展开,下文不再赘述。

工作进程

Nginx性能强大的一个重要原因在于它采用多进程非阻塞I/O模型,因此我们要妥善利用这一点:

  • worker_processes  默认的Nginx只有一个master进程一个worker进程,我们需要对其进行修改,可以设置为指定的个数,也可以设置为 auto,即系统的CPU核数。更多的worker数量将导致进程间竞争cpu资源,从而带来不必要的上下文切换。因此这里我们将它设置为cpu的核数即可:    worker_processes   auto

  • worker_connections每个worker可以处理的并发连接数,默认值512不是很够用,我们适当将它增大:    worker_connections 4096

  • Nginx支持以下I/O复用方法处理连接:selectpollkqueueepollrtsig/dev/polleventport。它们分别适用于不同的操作系统,其中 epoll是Linux系统上面效率最高的:   use epoll

KeepAlive

为了避免从Nginx到Web服务频繁的建立、断开连接,我们可以启用从HTTP 1.1开始支持的KeepAlive长连接特性,它可以大幅减少CPU和网络开销,在我们的实战中也是对性能提高最大的一环。keepalive必须和 proxy_http_versionproxy_set_header结合使用, 参考配置如下:

upstream BACKEND {    keepalive 300;    server 127.0.0.1:8081;}server {    listen 8080;    location / {        proxy_pass http://BACKEND;        proxy_http_version 1.1;        proxy_set_header Connection"";    }}

其中 keepalive既非timeout,也不是连接池数量,官方解释如下:

The connections parameter sets the maximum number of idle keepalive connections to upstream servers that are preserved in the cache of each worker process. When this number is exceeded, the least recently used connections are closed.

可以看出它的意思是“最大空闲长连接数量”,超出这个数量的空闲长连接将被回收,当请求数量稳定而平滑时,空闲长连接数量将会非常小(接近于0),而现实中请求数量是不可能一直平滑而稳定的,当请求数量有波动时,空闲长连接数量也随之波动:

  • 当空闲长连接数量大于配置值时,将会导致大于配置值的那部分长连接被回收;

  • 当长连接不够用时,将会重新建立新的长连接。

因此,如果这个值过小的话,就会导致连接池频繁的回收、分配、再回收。

为了避免这种情况出现,可以根据实际情况适当调整这个值,在我们实际情况中,目标QPS为6000,Web服务响应时间约为200ms,因此需要约1200个长连接,而 keepalive值取长连接数量的10%~30%就可以了,这里我们取300,如果不想计算,直接设为1000也是可行的。

Access-Log缓存

记录日志的I/O开销比较高,好在Nginx支持日志缓存,我们可以利用这个功能,降低写日志文件的频率,从而提高性能。可以将 bufferflush两个参数结合使用来控制缓存行为:

access_log /var/logs/nginx-access.log buffer=64k gzip flush=1m

其中 buffer制定了缓存大小,当缓冲区达到 buffer所指定的大小时,Nginx就会将缓存起来的日志写到文件中;flush指定了缓存超时时间,当 flush指定的时间到达时,也会触发缓存日志写入文件操作

文件描述符限制

上一节中已经对Linux系统的文件描述符限制进行了修改,Nginx配置中同样有相应的配置项:worker_rlimit_nofile, 理论上这个值应该设置为 /etc/security/limits.conf中的值除以worker_processes,但实际中不可能每个进程均匀分配,所以这里只要设置成和/etc/security/limits.conf一样就可以了

worker_rlimit_nofile 1000000

总结

以上就是笔者进行Nginx调优的一些经验,可以看出基本是围绕Nginx的Error日志展开的,之后又对一些比较大的性能瓶颈进行了一些改进。Nginx能够优化的地方非常多,本文只涉及到了其中很小的一些方面,但也足够满足我们的使用场景了。

关注我们

界世的你当不

只做你的肩膀

 360官方技术公众号 

技术干货|一手资讯|精彩活动

空·

<think>好的,我现在要帮助用户了解如何对Nginx进行性能以支持5000个并发请求。首先,我需要回忆一下Nginx性能化相关知识点。根据用户提供的引用内容,尤其是引用[2]和引用[4],里面提到了需要根据工作量,比如静态内容或动态内容的不同设置。还有关于文件缓存、FastCGI和代理缓存的区别。 首先,用户的目标是支持5000个并发请求。这意味着需要Nginx的并发处理能力。我应该从整worker进程开始。通常,worker_processes应该设置为等于或稍大于CPU核心数,这样可以充分利用多核性能。然后,每个worker的连接数(worker_connections)也需要增加,可能需要整系统的文件描述符限制。 接下来是连接多路复用,使用epoll在Linux上更高效。然后保持长连接,减少TCP握手次数,可以适当整keepalive_timeout和keepalive_requests。 关于静态资源,用户引用[2]提到open_file_cache的设置,这样可以缓存文件描述符,减少重复打开文件的消耗。需要配置open_file_cache的参数,比如max、inactive时间等。同时,sendfile和tcp_nopush可以提升静态文件传输效率。 动态内容方面,引用[4]指出fastcgi_cache用于PHP动态内容,而proxy_cache用于静态文件。如果用户有动态内容,可能需要整FastCGI缓存参数,如fastcgi_cache_path,设置缓存区域的大小和过期时间。 系统级化也很重要,比如整内核参数,包括最大打开文件数(ulimit -n)、TCP缓冲区大小(net.core.somaxconn,net.ipv4.tcp_tw_reuse等)。这些设置可以提升系统的整体并发处理能力。 然后,需要验证配置是否正确,使用nginx -t,然后重载配置。测试工具可以用ab或wrk模拟高并发请求,监控Nginx的状态,比如使用stub_status模块查看活动连接数。 可能还需要考虑其他化点,比如压缩(gzip),负载均衡,或者使用HTTP/2。同时,根据引用[3],用户提到了Test::Nginx,可能涉及到测试模块,但用户当前的问题可能暂时不需要,不过可以作为扩展建议。 用户的问题可能涉及到静态和动态内容的不同处理,需要明确应用场景。根据引用[1],用户之前对比过Nginx和lighttpd的性能,可能当前场景是静态内容为主,所以重点化文件缓存和连接管理。 最后,生成相关问题,引导用户进一步探讨性能分析、化方法对比以及监控工具等。</think>### Nginx性能方案 #### 1. 基础配置整 - **工作进程化** 设置`worker_processes`为CPU核心数(或`auto`自动检测),并通过`worker_connections`控制每个进程的并发连接数: ```nginx worker_processes auto; # 默认1,建议等于CPU核心数 events { worker_connections 4096; # 单进程最大连接数(需结合系统ulimit整) use epoll; # Linux高效事件模型 } ``` 总并发量计算公式: $$最大并发 = worker\_processes \times worker\_connections$$ - **系统资源限制** 修改Linux文件描述符限制以支持更多连接: ```bash ulimit -n 65536 # 临时生效 # 永久生效需在/etc/security/limits.conf添加: * soft nofile 65536 * hard nofile 65536 ``` #### 2. 连接管理化 ```nginx http { keepalive_timeout 60; # 保持TCP连接复用时间 keepalive_requests 1000; # 单连接最大请求数 reset_timedout_connection on; # 超时后释放资源 } ``` #### 3. 静态资源加速 引用[2]中提到的文件缓存配置可减少磁盘IO: ```nginx http { open_file_cache max=2048 inactive=20s; # 缓存文件元信息 open_file_cache_valid 30s; # 缓存校验周期 open_file_cache_min_uses 2; # 至少访问2次才缓存 sendfile on; # 零拷贝传输模式(于read+write) tcp_nopush on; # 合并数据包减少网络开销 } ``` #### 4. 动态内容处理 若涉及PHP/Python等动态内容,需化FastCGI(引用[4]): ```nginx location ~ \.php$ { fastcgi_cache_path /tmp/nginx_cache levels=1:2 keys_zone=phpcache:100m inactive=60m; fastcgi_cache phpcache; fastcgi_cache_valid 200 301 302 10m; # 缓存HTTP 200等状态码内容 fastcgi_pass unix:/var/run/php-fpm.sock; } ``` #### 5. 操作系统内核 ```bash # 整TCP参数(/etc/sysctl.conf) net.core.somaxconn = 65535 # 最大待处理连接数 net.ipv4.tcp_tw_reuse = 1 # 快速回收TIME-WAIT连接 net.ipv4.tcp_max_syn_backlog = 65536 ``` #### 6. 压力测试与监控 - **测试工具** ```bash ab -n 100000 -c 5000 http://yourdomain.com/ wrk -t12 -c5000 -d30s http://yourdomain.com/ ``` - **状态监控** 启用`stub_status`模块: ```nginx location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; deny all; } ``` 输出示例: ``` Active connections: 234 server accepts handled requests 456789 456789 987654 ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值