频道栏目
首页 > 网络 > 疑难 > 正文

一个链接引发的血案---------服务器 IO及网络流量暴涨解决历程

2014-08-05 21:42:22      个评论      
收藏   我要投稿

 在这里介绍一次因为更改网站地址而引发服务器IO读取速度,网络流入流出速度暴涨10倍的解决经历。

环境:Ubuntu + Nginx + php-cgi + Wordpress

事情是这样的,现在网站使用的wordpress搭建的,网址为www.main.com(一个例子), 因为要启用新站点news.main.com,于是开启wordpress multi sites的功能。

开启MS功能过程中,受Wordpress MS 本身的限制,需要将之前的www.main.com更改为main.com, 这样子才能添加网站news.main.com。 否则就成了news.www.main.com。

 

在一个月黑风高的晚上把网址作了更改,开启了Multi Site功能,访问都没问题,为了万全,还在发布新文章试试,一切OK后,就上床睡觉去了。

早上起来第一件事就是看网站能不能正常打开,到监控监控页查看各项资源。惊讶的发现IO读写速度,网络流入流出速度都出现了十倍的增长。下面是正常情况下的数字(依次是CPU, IO读速度,IO写速度,网络流出速度,网络流入速度),出问题时的截图没有保留下来,但记得IO读写速度都在250k/s左右,网络流出速度在2M~5M之间,流入速度也在100k左右。

\

这样子真的莫名其妙了,第一反应是难道某些插件不支持多站模式,特别是一些缓存插件。但觉得暂时还是不要怀疑这些插件,那些都是很成熟的插件,一时也没有时间去研究他们的代码去找原因。先把现象搞清楚,得先根上找原因。

 

 

因为在更改wordpress配置时,也把ubuntu系统进行了一些update,所以先找找是否有什么异常的服务或者一些特殊的端口。

 

1. 首先用netstat -tunlp

\

这些都是一些常用的msql, memcache, http,ssh, postfix, php-cgi的所需端口。68也是一个以前就开了的端口,网上查了,是DHCP 用的。

2. 另外一个和netstat差不多的命令nmap localhost:

\

没有异常的东西。(有点纳闷为什么没有memcache的11211了)

3. 利用chkconfig -list查看一下开机启动的服务。没有什么发现。

 

 

系统服务上没有找到可疑这处,就再查看一下网络流量,在网上查找了一些别人在这方面的经验,首先有人推荐了nethogs.

 

1. nethogs eth0

\

上图是正常情况下的数据。异常情况下时,也只能看到是nginx workproses的sent/received很大,但还是看不出来网站具体是哪里出问题了。

2. 另外一个监控网络的同类型软件:iftop

sudo iftop -n -B -m 3000000

\

显示如上,其实到这里后我的思路就是先找出对应的IP后,再直接在nginx access日志中就可以找出对应是哪个文件频繁读取了。但当时日志确实也出现了一些问题,在iftop中显示的这些ip竟然不在我的nginx access日志,以至我怀疑难道这些ip是不是在访问我电脑上别的80端口,心杨这是不可能的吧。于是暂时放下继续找到底是哪些文件在频繁被读取呢?

ps: 在这里做了一个尝试,将显示流量高的ip加到防火墙里,没有影响。

 

 

下一步,是为什么io那么高呢,能不能搞清楚是哪个文件在频繁被读写呢?

另外,之前也出过类似的问题,是因为日志切割不成功导致网站日志太大而io太大,先检查一下nginx网站日志。

1. 检查日志分割

发现日志确实有点大,但也没有大到离谱的地步,就立即执行了一次人工分割。logrotate -vf /etc/logrotate.conf

2. iotop。

如下所示,还是只显示出来哪一个进程在用,而不是具体哪个文件被用。

\

3. 记得有一个可以列出所有打开的文件的命令的,最后了才试试这个: sudo lsof +s -n 

开始的时候把每一条都列出来,一一查找异常。 在其中先看到我的nginx access日志读写,都还正常;再在后面的确发现了几个对我服务器图片的读取。于是:

sudo lsof +s -n | grep public_html

(public_html是我的网站目录)

\

然后在nginx access日志里面一查找,如下:

222.85.131.142 - - [12/Jul/2013:14:11:30 +0800] "GET /wp-content/uploads/2013/07/IMG_0604.jpg HTTP/1.1" 404 31 "-" "null (FlipboardProxy/1.1; +http://flipboard.com/browserproxy)" - 0.088 0.088 - 222.85.131.142 - - [12/Jul/2013:14:11:31 +0800] "GET /wp-content/uploads/2013/07/IMG_0604.jpg HTTP/1.1" 404 31 "-" "null (FlipboardProxy/1.1; +http://flipboard.com/browserproxy)" - 0.104 0.104 - 221.233.53.238 - - [12/Jul/2013:14:11:35 +0800] "GET /wp-content/uploads/2013/07/IMG_0604.jpg HTTP/1.1" 404 31 "-" "null (FlipboardProxy/1.1; +http://flipboard.com/browserproxy)" - 0.082 0.082 - 222.85.131.142 - - [12/Jul/2013:14:11:37 +0800] "GET /wp-content/uploads/2013/07/IMG_0604.jpg HTTP/1.1" 404 31 "-" "null (FlipboardProxy/1.1; +http://flipboard.com/browserproxy)" - 0.090 0.090 - 222.85.131.142 - - [12/Jul/2013:14:11:42 +0800] "GET /wp-content/uploads/2013/07/IMG_0604.jpg HTTP/1.1" 404 31 "-" "null (FlipboardProxy/1.1; +http://flipboard.com/browserproxy)" - 0.099 0.099 - 183.219.208.255 - - [12/Jul/2013:14:11:45 +0800] "GET /wp-content/uploads/2013/07/IMG_0604.jpg HTTP/1.1" 404 31 "-" "null (FlipboardProxy/1.1; +http://flipboard.com/browserproxy)" - 0.117 0.117 - 222.85.131.142 - - [12/Jul/2013:14:11:46 +0800] "GET /wp-content/uploads/2013/07/IMG_0604.jpg HTTP/1.1" 404 31 "-" "null (FlipboardProxy/1.1; +http://flipboard.com/browserproxy)" - 0.116 0.116 - 221.233.53.238 - - [12/Jul/2013:14:11:48 +0800] "GET /wp-content/uploads/2013/07/IMG_0604.jpg HTTP/1.1" 404 31 "-" "null (FlipboardProxy/1.1; +http://flipboard.com/browserproxy)" - 0.084 0.084 -

 

上面只是一部分,原来是从Flipboard来的。(还有一个疑问,第一次的时候在nginx.access日志竟然查找不到lsof里显示的文件)

纳闷,我们配置了cdn,怎么会有这么量大的图片访问跑到我们服务器上来呢,于是找到了包含这个图片的文章,一查看源码,图片地址果然是我们自己服务器的地址而不是cdn的服务器。至此,情况渐渐明了:

我的cdn功能是这么实现的:将文章内我们网站地址链接都更换成cdn服务器的。之前网站地址配置为http://www.main.com时,文章里的图片链接都是http://www.main.com, 我现在将主站地址配置为http://main.com后,cdn功链接替换也只对http://main.com有效了,于是以前的那些文章中的图片都没有cdn功能了,悲剧了。

找到问题之后,就好办了,试验了一个sql脚本,就在当天晚上在服务器数据库上跑一遍,并且清空一下服务器缓存。

但还有一个小插曲,第二天到了公司后,发现io还是很高。虽然比之前降了不少,于是按照上面的方法查找哪些文件被这么频繁读取,查了之后还是上面那个图片(IMG_0604)特别多。发现是从Flipboard来的,于是找旁边一个同事借了他的ipad用Flipboard看了一下这篇文章,但不知道如何在ipad里查看图片源链接。一看到是Flipboard心里差不多明白了:之前还替Flipboard准备过一个专门的rss输出的,而且rss是有很变态的缓存,肯定是Flipboard缓存了这篇文章而且不带cdn效果,碰巧这篇文章还挺热闹,给我们引入了大的PV的同时也增加了我们的负载。

 

上一篇:AMR是什么类型文件 amr用什么播放器打开?
下一篇:故障诊断复习
相关文章
图文推荐

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训 | 举报中心

版权所有: 红黑联盟--致力于做实用的IT技术学习网站