高并发下nginx调优实战
1.nginx优势说明
a. 占有内存少 (在3W并发连接中，开启的10个nginx进程消耗内存大约150M)
b. 高并发能力强 (官方测试能够支撑5W并发连接，在实际生产环境中能到2-3W并发连接数)
c . 简单 (配置文件通俗易懂)
d . 价格 (免费、开源)
e. 支持Rewriter重写 (能够根据域名、URL的不同，将HTTP请求分到不同的后端服务器群组)
f. 内置健康检查 (如果nginx后端有几个服务宕机了，不会影响前端访问，能自动检测服务状态)
g. 节省带宽 (支持GZIP压缩，可以添加浏览器本地缓存的Header头)
h. 稳定性高，反向代理，很少宕机
i .中国大陆使用nginx网站用户有：百度、京东、新浪、网易、腾讯、淘宝等
2.场景说明
- 测试数据：由于后端服务器采用集群部署，通过性能测试工具jmeter分析出后端服务端处理用户每秒请求数（QPS）的单并发峰值在8千左右。
- 问题分析途径：nginx日志。
1、通过访问日志，你可以得到用户地域来源、跳转来源、使用终端、某个URL访问量等相关信息。
2、通过错误日志，你可以得到系统某个服务或server的性能瓶颈等
- 调优过程：实现nginx限流、安全配置、优化进程数及并发连接数、nginx状态监控等性能调优。
- 调优结果：当用户请求数达到此峰值时实现限流，保证有效的请求通过nginx转发给后端成功处理。ps:如果不做限流处理当请求数超过峰值时，有效的8千请求也会失效，造成服务器的宕机。
3. nginx日志切割实现
- nginx日志默认没有分割，使用起来非常不方便
[root@bogon logs]# ll
总用量 24
-rw-r--r--. 1 root root 17403 2月 8 17:09 access.log
-rw-r--r--. 1 root root 186 2月 7 17:39 error.log
[root@bogon logs]# ll
总用量 24
-rw-r--r--. 1 root root 17628 2月 9 14:38 access.log
-rw-r--r--. 1 root root 186 2月 7 17:39 error.log
- 解决方法-通过shell脚本实现日志切割
其中上篇文章https://www.jianshu.com/p/42d44d8a0f29介绍了docker容器运行nginx镜像并加载nginx.conf配置文件，日志路径为：/data/nginx/logs目录下
- shell脚本如下：
#!/bin/bash
#设置日志文件存放目录
LOG_HOME="/data/nginx/logs/"
#备分文件名称
LOG_PATH_BAK="$(date -d yesterday +%Y%m%d%H%M)".access.log
#重命名日志文件
mv ${LOG_HOME}/access.log ${LOG_HOME}/${LOG_PATH_BAK}.log
#向nginx主进程发信号重新打开日志
kill -USR1 `cat /opt/nginx/logs/nginx.pid
- 创建crontab设置定时任务
*/1 * * * * sh /data/nginx/nginx_log.sh
[root@bogon logs]# ll
总用量 16
-rw-r--r--. 1 root root 1238 2月 9 17:44 202002081743.access.log
-rw-r--r--. 1 root root 2588 2月 9 17:45 202002081745.access.log
-rw-r--r--. 1 root root 0 2月 9 17:46 access.log
-rw-r--r--. 1 root root 0 2月 9 17:10 error.log
4.并发AB工具简介
- 相对性能测试工具jmeter而言，在Linux下ab工具更轻巧好用。BA命令简介：
key含义Document Path测试的页面Document Length页面的大小Concurrency Level并发数量、并发用户数Time taken for tests测试耗费总时间Complete requests请求总量、并发连接数Failed requests请求失败的数量Write errors错误数量Requests per second每秒钟的请求量、吞吐率Time per request每次请求需要时间、响应时间
- Centos安装命令：
yum install httpd-tools –y
- 测试并发命令：
ab -c 1 -n 6 http://192.168.1.90:8070/index/index.html
192.168.1.91 - - [09/Feb/2020:11:55:23 +0000] "GET /index/index.html HTTP/1.0" 200 20 "-" "ApacheBench/2.3" "-"
192.168.1.91 - - [09/Feb/2020:11:55:23 +0000] "GET /index/index.html HTTP/1.0" 200 150 "-" "ApacheBench/2.3" "-"
192.168.1.91 - - [09/Feb/2020:11:55:23 +0000] "GET /index/index.html HTTP/1.0" 200 20 "-" "ApacheBench/2.3" "-"
192.168.1.91 - - [09/Feb/2020:11:55:23 +0000] "GET /index/index.html HTTP/1.0" 200 150 "-" "ApacheBench/2.3" "-"
5. nginx限流有三种方式实现
• limit_conn_zone
• limit_req_zone
• ngx_http_upstream_module
前两种只能对客户端（即单一ip限流）
- ngx_http_upstream_module限流示例(推荐)
• 该模块是提供了我们需要的后端限流功能的
• 该模块有一个参数：max_conns可以对服务端进行限流，版本要求：在nginx1.11.5版本以后，配置参数：
upstream localhost{
server 192.168.1.90:8071 max_conns=5;
server 192.168.1.90:8072 max_conns=5;
}
- 执行结果【可以看到结果有一个已经错误了，同理可以限制服务端访问流量】：
[root@bogon ~]# ab -c 1 -n 6 http://192.168.1.90:8070/index/index.html
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 192.168.1.90 (be patient).....done
Server Software: nginx/1.17.8
Server Hostname: 192.168.1.90
Server Port: 8070
Document Path: /index/index.html
Document Length: 150 bytes
Concurrency Level: 1
Time taken for tests: 0.041 seconds
Complete requests: 6
Failed requests: 0
Write errors: 1
Total transferred: 2328 bytes
HTML transferred: 900 bytes
Requests per second: 146.03 [#/sec] (mean)
Time per request: 6.848 [ms] (mean)
Time per request: 6.848 [ms] (mean, across all concurrent requests)
Transfer rate: 55.33 [Kbytes/sec] received
6. 高并发下Nginx安全配置
- 版本安全
Accept-Ranges: bytes
Connection: keep-alive
Content-Length: 20
Content-Type: text/html
Date: Sun, 09 Feb 2020 11:42:08 GMT
ETag: W/"20-1581064798000"
Last-Modified: Fri, 07 Feb 2020 08:39:58 GMT
Server: nginx/1.17.8
- 响应头信息可以看到nginx的版本号，版本号暴露是不安全的，所以需要隐藏下nginx的版本号，配置server_tokens off;下面就看不到了。
http {
server_tokens off;
...
Accept-Ranges: bytes
Connection: keep-alive
Content-Length: 150
Content-Type: text/html
Date: Sun, 09 Feb 2020 11:45:09 GMT
ETag: W/"150-1581063242000"
Last-Modified: Fri, 07 Feb 2020 08:14:02 GMT
Server: nginx
- IP安全配置
白名单配置：
location / {
allow 192.168.136.1;
deny all;
}
黑名单设置：
location / {
deny 192.168.136.1;
allow all;
}
- 文件安全配置
location /logs {
autoindex on;
root /opt/nginx/;
}
location ^/logs~*\.(log|txt)$ {
add_header Content-Type text/plain;
root /opt/nginx/;
}
7. Nginx配置进程数、并发数、系统优化
- 调整Nginx的主配置文件,增加并发量
worker_processes 2; #调整到与CPU数量一致
events {
worker_connection 65535; #每个worker最大并发连接数
}
- 调整内核参数
[root@proxy ~]# ulimit -a #查看所有的属性值
[root@proxy ~]# ulimit -Hn 10000 #临时设置硬限制
[root@proxy ~]# ulimit -Sn 10000 #设置软限制
[root@proxy ~]# vim /etc/security/limits.conf
...
* soft nofile 100000
* hard nofile 100000
用户/组 软/硬限制 需要限制的项目 限制的值
- 验证
ab -n 1 -c 20000 http://192.168.1.131/
8.高并发下Nginx状态监控
- 配置Nginx的监控选项(配置文件路径：nginx.conf)
添加如下代码：
#设定Nginx状态访问地址
location /NginxStatus {
stub_status on;
access_log off;
}
- 插件安装(在源码目录下执行)：
./configure --prefix=/opt/nginx/ --with-http_stub_status_module
- 参数说明：
活跃的连接数量
active connections
总共处理了n个连接 , 成功创建n次握手, 总共处理了n个请求
server accepts handled requests
每个连接有三种状态waiting、reading、writing
reading —读取客户端的Header信息数.这个操作只是读取头部信息，读取完后马上进入writing状态，因此时间很短
writing — 响应数据到客户端的Header信息数.这个操作不仅读取头部，还要等待服务响应，因此时间比较长。
waiting — 开启keep-alive后等候下一次请求指令的驻留连接.
正常情况下waiting数量是比较多的，并不能说明性能差。反而如果reading+writing数量比较多说明服务并发有问题。
查看Nginx并发进程数：ps -ef|grep nginx | wc -l
查看Web服务器TCP连接状态：netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
- 解析：
CLOSED //无连接是活动的或正在进行
LISTEN //服务器在等待进入呼叫
SYN_RECV //一个连接请求已经到达，等待确认
SYN_SENT //应用已经开始，打开一个连接
ESTABLISHED //正常数据传输状态/当前并发连接数
FIN_WAIT1 //应用说它已经完成
FIN_WAIT2 //另一边已同意释放
ITMED_WAIT //等待所有分组死掉
CLOSING //两边同时尝试关闭
TIME_WAIT //另一边已初始化一个释放
LAST_ACK //等待所有分组死掉
查看Web服务器TCP连接状态：netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
最后并发超过峰值后的服务端jvm监控显示正常
