打趴系统的不一定是技术

五一节就这么废了，因为线上服务器负载一直飙高。

aaa.png

负载这么高，居然还能登录系统进行操作，佩服佩服。

这是一套新上线的业务，购买的是阿里云的主机及服务。业务请求先到负载均衡，业务承载由2台云主机来担当，缓存redis直接购买服务，mysql数据库也是购买现成的服务。这意味着，能直接进行维护操作的，就是两台云主机，上边部署了nginx、php，以及必须的php扩展。

登录上系统后，常用的套路有：查看进程、查看负载、查看网络连接情况、查看系统日志、查看web日志、查看php日志（错误日志、慢查询日志）、查看数据库状况...

1、查进程数，发现php进程数量保持一个恒定的数值。这说明php开启的进程数到达设定的最大值，资源占完，又不能正常释放。通过修改配置php-fpm.conf，重启php观察其运行情况，修改后的配置文件如下：

[global]

pid = /usr/local/php/var/run/php-fpm.pid

error_log = /usr/local/php/var/log/php-fpm.log

log_level = notice

[www]

listen = 127.0.0.1:9000

;listen = /dev/shm/php-cgi.sock

listen.backlog = -1

listen.allowed_clients = 127.0.0.1

listen.owner = www

listen.group = www

listen.mode = 0666

user = www

group = www

pm = dynamic

pm.max_children = 2000

pm.start_servers = 100

pm.min_spare_servers = 20

pm.max_spare_servers = 100

;access.log = /home/wwwroot/logs/phplog/$pool.access.log

access.log = /home/wwwlogs/phplog/$pool.access.log

access.format = "%R - %u %t \"%m %r%Q%q\" %s %f %{mili}d %{kilo}M %C%%"

pm.max_requests = 102400

request_terminate_timeout = 4s

request_slowlog_timeout = 2

slowlog = /home/wwwlogs/phplog/slow.log

说明：access.log这行，原来程序员配置的日志路径是一个共享NAS，php代码发布在其上，两台云主机同时对它进行读写，担心两台机器同时对同一个文件打开和写入会带来io上的负担，因此把日志写入本地路径/home/wwwlogs/phplog.

blob.png

通过上述修改以后，php的进程数基本处于正常，但对负载降低的作用还是很有限。查看php日志，滚屏得飞快。

2、查看网络状况，算不上异常，输出如下：

[root@web1 ~]# netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

LAST_ACK 54

SYN_RECV 6

ESTABLISHED 528

FIN_WAIT1 33

TIME_WAIT 5641

修改了系统文件/etc/sysctl.conf，重新加载，效果改善不明显。

3、流量检查，用了两个工具iftop和iptraf，从输出可以判断，基本在可接受的范围。但有个ip地址，其一直排在流量第一位，有点可疑，是什么业务呢？

blob.png

执行 netstat -anp|grep 172.31.176.238 进一步核实，是对redis的请求，看起来还不少呢！

[root@web1 ~]# netstat -anp|grep 172.31.176.238|wc -l

3197

两台主机都查了，加起来得有7000左右的请求，不太正常吧！

3、最近借服务器挖矿很流行，担心被入侵，拿acunetix一通猛扫，未见异常；又拿360认证后扫一遍（webscan.360.cn，不是windwos安装的安全卫士一类），也一无所获。再仔细检查文件、系统安全日志、帐号文件等，基本可以判断没有被入侵。

折腾了好几天，这些招数都不灵，白天负载高都还想得通，用户在访问嘛。可是稀奇的是，当通过调整，负载降下去了，到凌晨的时候，又开始飙升。不得意，在nginx做访问限制，其主要配置如下：

 map $request_method $limit {

        default         "";

        POST            $binary_remote_addr;

        }

        limit_conn_zone $binary_remote_addr zone=one_limit:10m;

        limit_req_zone $limit zone=zone_limit_post:10m rate=10r/m;

访问量大的站点，再单独插入如下的行：

limit_req zone=zone_limit_post burst=5;

说明：前边一段代码，插入到nginx主配置文件里边；后边一段，插入到具体站点配置server的 location那段里边。如果位置不对，做语法检查会报错，当然也就启动不了nginx。

重载nginx后，负载稍微有所下降，但相关部门反馈，这限制影响大用户访问了。

五一假期都结束了，尝试了多种办法，效果还是不理想。于是我就打算自己下载app，安装在手机上，了解一下客户端的访问行为。开打app以后，底部菜单栏三个:快讯、行情、我的。其中“快讯”又分几个板块--快讯、动态、微博、教程。

blob.png

通过点击菜单和对比服务器，发现两个问题：

1、不管点不点“行情”，客户端都会疯狂地去抓取行情数据。通过web访问日志可以看到同一个ip，对同一对象发起的频繁请求（“POST /index.php?_url=/market/list&”）。通过与其他技术人员沟通，证实了我的猜测，客户端每秒钟会发起大概20次的请求，只要app开着。

blob.png

2、只要打开了app，不管是否需要，都会全部读取所有的信息。通过“快讯”这一屏显示内容，手指一直往上滑，一直都有内容。而我拿别人家的app做对比，别的app是上滑的过程，会有一个短暂的加载过程，即需要数据的时候，才真正去抓取和加载。

掌握这些信息后，赶紧电话跟其它人沟通，强烈建议更细app，改变现在这种无限制读取数据的方法。相关人员也意识到问题确实由此引起，承诺尽快处理。但本文撰写进行时，据称目前已经强制更新了大概50%的客户端。从服务器端看负载，趋势逐渐好转。

©著作权归作者所有：来自51CTO博客作者sery的原创作品，如需转载，请注明出处，否则将追究法律责任

区块链linux云主机《互联网运营智慧》