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

在这里介绍一次因为更改网站地址而引发服务器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的同时也增加了我们的负载。