在這里介紹一次因為更改網站地址而引發服務器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的同時也增加了我們的負載。