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

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%的客户端。从服务器端看负载,趋势逐渐好转。