0

阿里云服务器IO偏高后,我的折腾之路

Posted by 撒得一地 on 2016年1月12日 in 生活

前一阵子,网站经常打不开。刚开始还比较无所谓,以为是阿里云服务器某些线路不稳定造成的。直到后来几乎天天收到百度云监控的短信报警和邮件报警(我的站点开启了百度云监控,因为误报和监控频率过高百度云监控口碑不是很好)。一开始还以为是百度云监控误报,但后面只要一有报警,我就赶紧访问我的站点,发现还真的访问不了,而且经常连远程控制台都打不开了。

后面排查了日志,发现一些恶意访问日志:

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偏高后,我的折腾之路

网上查阅了一些解决硬盘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分区和删除swap分区

Swap分区配置完后,效果果然很明显,一两个恶意ip并发探测访问虽然IO读写也会偏高,但至少内存不会瞬间耗尽。

IO偏高陆陆续续折腾了大半个月,折腾过程虽诸多不尽人意,但真的还是逼自己学了挺多东西。要是没这个问题,也不会去使用CDN,与及Wp Super Cache缓存插件等。

看来,人生贵在折腾,不折腾不成魔,还是很有道理的。

后面还要折腾得是,看能不能写个脚本,把恶意探测ip用程序自动拉黑,而不用每次手动写iptables。

转载请注明:http://coderschool.cn/1488.html

标签:

上一篇:

下一篇:

相关推荐

发表评论

电子邮件地址不会被公开。 必填项已用*标注

5 + 6 = ?

网站地图|XML地图

Copyright © 2015-2017 技术拉近你我! All rights reserved.
闽ICP备15015576号-1,版权所有©psz.