阿里云服务器IO偏高后，我的折腾之路
下一篇: 我记录的一些肮脏IP(持续更新)
前一阵子，网站经常打不开。刚开始还比较无所谓，以为是阿里云服务器某些线路不稳定造成的。直到后来几乎天天收到百度云监控的短信报警和邮件报警(我的站点开启了百度云监控，因为误报和监控频率过高百度云监控口碑不是很好)。一开始还以为是百度云监控误报，但后面只要一有报警，我就赶紧访问我的站点，发现还真的访问不了，而且经常连远程控制台都打不开了。
后面排查了日志，发现一些恶意访问日志：
103.36.52.82 - - [10/Jan/2016:23:34:20 +0800] "POST /plus/cere.php HTTP/1.1" 404 14058 103.36.52.82 - - [10/Jan/2016:23:34:20 +0800] "POST /plus/cere.php HTTP/1.1" 404 14058 103.36.52.82 - - [10/Jan/2016:23:34:21 +0800] "POST /plus/360.php HTTP/1.1" 404 14058 103.36.52.82 - - [10/Jan/2016:23:34:21 +0800] "POST /plus/360.php HTTP/1.1" 404 14058 103.36.52.82 - - [10/Jan/2016:23:34:22 +0800] "POST /data/safe/360.php HTTP/1.1" 404 14058 103.36.52.82 - - [10/Jan/2016:23:34:22 +0800] "POST /data/safe/360.php HTTP/1.1" 404 14058 103.36.52.82 - - [10/Jan/2016:23:34:28 +0800] "POST /include/helperss/filter.helpear.php HTTP/1.1" 404 14058 103.36.52.82 - - [10/Jan/2016:23:34:28 +0800] "POST /include/helperss/filter.helpear.php HTTP/1.1" 404 14058 ...
也查了一些之前的日志，发现存在很多类似的访问记录。因为阿里云盾功能还是挺强大的，所以一般的漏洞攻击都会被拦截，但这一类IP却逃过了云盾法眼。仔细的看了下这类IP的访问路径，发现都是访问一些站点不存在的路径，我猜测，这类IP是通过站点探测来寻找站点漏洞。所以初步判断，网站打不开就是因为这类恶意IP像采集器一样并发的探测访问我的博客。
不过虽然我的带宽只有1M，但也不至于被一个恶意IP搞垮吧。于是在阿里云控制台查了下CPU，发现CPU使用率也就10%左右,看来CPU没问题。随后，查看硬盘情况，发现硬盘IO读写非常高，看图：
网上查阅了一些解决硬盘IO偏高的相关资料，由于对这一块了解的很少，毫无头绪，无奈只能开启工单咨询阿里技术人员。阿里技术人员的回复是，安装iotop查看哪个进程IO读写高。因为iotop和top命令相似，都是实时监控的，而且我的博客平时IO都很正常，只有一些恶意IP持续访问时才会出现IO偏高。所以用iotop查看对我来说作用不大，因为不知道恶意IP什么时候会来访问我的站点。于是想通过写日志的方式进行记录，又发现写日志记录进程读写情况并不是那么容易，泪奔。
再一次求助阿里技术人员，希望提供个能记录进程读写日志的脚本。阿里技术人员回复说这个只能自己去折腾，超出他们范围。反复求助后，估计他们也有点烦了，技术人员索要ESC权限帮我查日志，感激涕零(更反映自己对运维方面了解太少，要加强学习==)。
阿里技术人员最后查出的问题是，httpd占用过高，导致最后内存不够用：
[root@lmode ~]# cat /var/log/messages | grep mem | more Jan 3 06:34:49 lmode kernel: lowmem_reserve[]: 0 0 0 0 Jan 3 06:34:49 lmode kernel: Out of memory: Kill process 3300 (httpd) score 255 or sacrifice child Jan 3 06:36:54 lmode kernel: httpd cpuset=/ mems_allowed=0 Jan 3 06:36:54 lmode kernel: [] out_of_memory+0x263/0x320 Jan 3 06:36:54 lmode kernel: mapped:428 shmem:105 pagetables:1152 bounce:0 </ffffffff81133ac3>
我的博客物理内存是1G，平时pv数较少，难道还要扩大内存?用free -m 查了下内存使用情况:
[root@iZ94aucqfjcZ /]# free -m total used free shared buffers cached Mem: 995 419 576 0 8 38 -/+ buffers/cache: 372 623 Swap: 0 0 0
大部分时间内存使用情况都很正常。其实大家很容易发现，Swap分区为0，阿里云默认是没有分配Swap分区的。但当时的我竟然毫无发觉，心里只顾着思索httpd进程内存占用过高是不是程序有问题，或者使用缓存会不会解决相应问题。
于是决定使用PHP静态缓存，这样减少了Mysql读写次数，PHP文件也不用每次都进行编译。Wordpress下比较出名的缓存插件工具是Wp Super Cache，网上相关资料很多，便开始捣鼓安装它，安装过程省略之，这部分感兴趣的可以参考:
WordPress下Wp Super Cache缓存插件安装和配置(详细版)。
安装完后，试用一下感觉很不错，访问速度也确实有所提高。然后心满意足的去干别的事情了。隔天，博客再一次因为恶意ip持续访问导致内存不足，IO读写偏高，然后许久打不开，连远程ESC都连接不上(因为内存耗光，无法分配内存)。
心里非常生气，技术nb的haker，有本事你去黑360、百度这样的大站，对我们这样的小网站这么持之以恒做啥。ESC连不上无奈只好关闭服务器一段时间，然后重启，查阅了访问日志，一堆404访问记录，赶紧将ip拉黑。
看来静态缓存还是解决不了恶意访问导致的内存耗尽的问题，于是捣鼓使用CDN。用了下百度免费的CDN，发现百度免费CDN确实不咋滴，回源经常出问题。360CDN口碑很不错，可惜错过了免费阶段，现在好像也收费了。最后还是使用阿里云的CDN，因为服务器本身就是阿里云的，这样就省去很多事。CDN开通后，站点访问速度好像有提高了一丢丢，不知道是不是心理作用。只是，恶意IP还是经常光顾，然后内存耗尽后，站点依旧打不开。真的是心力交瘁，心里一万只草尼马。
当然，上面的两次折腾其实都是治标不治本，只是起到了一定的优化作用。束手无策之际，本想再花钱扩大内存，忽然间恍然大悟，肯定是没设置Swap分区的原因。物理内存耗尽后，如果有Swap分区，至少还能再抵挡一阵子内存消耗。于是便开始配置Swap分区，配置过程省略，可以参考:
Swap分区配置完后，效果果然很明显，一两个恶意ip并发探测访问虽然IO读写也会偏高，但至少内存不会瞬间耗尽。
IO偏高陆陆续续折腾了大半个月，折腾过程虽诸多不尽人意，但真的还是逼自己学了挺多东西。要是没这个问题，也不会去使用CDN，与及Wp Super Cache缓存插件等。
看来，人生贵在折腾，不折腾不成魔，还是很有道理的。
后面还要折腾得是，看能不能写个脚本，把恶意探测ip用程序自动拉黑，而不用每次手动写iptables。
下一篇: 我记录的一些肮脏IP(持续更新)