记一次Nginx的配置优化运维

        运维的某一系统，用户达200w+,峰值浏览量500w+/每小时，系统技术架构是以Nginx为负载均衡分流的五台32G内存的Centos 7服务器。在一次节日大促活动中，该用户端(微信)告警如下：

Appid: wx42d69bbdca973c57
昵称: XX商城
时间: 2019-05-11 08:55:02
内容: 微信服务器向公众号推送消息或事件后，开发者5秒内没有返回
次数: 5分钟 6515次
错误样例: [OpenID=ogejHwfzw0XOfq0i5UDqFV3rZs4Q][Stamp=1583888102][3rdUrl=https://XXX.XXXXXX.com/ents/wechat/msg/wx42d69bbdca973c07.action][IP=219.146.118.229][Msg=Subscribe][Event=Subscribe]
报警排查指引，请见: https://w.url.cn/s/A1dMqXI

接到告警，立即先对5台服务器的CPU的性能负载，内存的性能负载进行查看

#查看CPU的性能负载
top

uptime

#查看内存的性能负载
free -m

特别是使用top命令对5台服务器的cpu使用情况查看时，利用率均打满（超过100%），造成接口请求很慢，很容易超时异常。这时最暴力的方法就是加机器扩内存提性能，但是毕竟财力有限，还是得挑战运维人员的工作能力的。毕竟这只是访问洪峰期时的状态，优化优化应该还可以正常使用。

接下来对告警内容进行分析：

1. 查看是否网络环境问题。已经查过，没有任何问题
2. 查看接入层服务器连接数，负载，nginx的配置，允许的连接个数。查看nginx错误日志是否有“Connection reset by peer”或“Connection timed out”错误日志，如有说明nginx连接数过超负载。
3. 搭建测试工具，对系统进行心跳检查，对系统负载，连接数，处理数，处理耗时进行实时监控报警。重点关注连接数配置，日志配置等。

1.这里主要是先查看系统的句柄配置情况

[[email protected] ~]$ ulimit -n 
1024

这里的设置的数字远小于请求的数量

先修改文件描述符文件

vim /etc/security/limits.conf 

soft nofile 655360

hard nofile 655360

把以上两行内容加到 limits.conf文件

2.查看系统的网络连接数情况确认是否有较大的连接数

[[email protected] ~]$ netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
LAST_ACK 1
CLOSE_WAIT 1
ESTABLISHED 287
FIN_WAIT2 8
TIME_WAIT 11
SYN_SENT 2

3.检查错误日志情况

tail -f logs/error_log

查看是否有connect() failed、Connection refused、 Connection reset by peer等error错误日志，有则说明有可能nginx出现的连接数超负载等情况。

4.检查完毕后修改Nginx的配置文件为如下：

vim nginx.conf

worker_processes  8;          //CPU核数
#error_log  logs/error.log error;
error_log  logs/error.log  info;   //错误日志log
worker_rlimit_nofile 102400;     //打开最大句柄数
events {
    worker_connections  102400;   //允许最大连接数
}
//请求日志记录，关键字段：request_time-请求总时间，upstream_response_time后端处理时 间
log_format  main  '$remote_addr  - $remote_user [$time_local] "$request" '
                 '$status $body_bytes_sent "$http_referer" '
                  '"$http_user_agent" "$http_x_forwarded_for" "$host"  "$cookie_ssl_edition" '
                 '"$upstream_addr"   "$upstream_status"  "$request_time"  '
                 '"$upstream_response_time" ';
access_log  logs/access.log  main;

此次优化主要是从Nginx的连接数超负载造成的，项目自一上线开始，配置一直没有做任何改动，直到用户数像滚雪球一样，越用越多，系统就支撑不住了，需要调整连接数>请求数，添加Nginx的error.log等运维日志，方便查看请求失败的情况，和以后的运维工作。