這次網絡堵車（請求執行時間長，響應速度慢）故障經過見之前的博文：雲計算之路-黎明前的黑暗：20130424網站故障經過
這次故障是memcached服務器引起的。這台雲服務器購買時間是2013-02-21，操作系統是CentOS 6.2 64位，配置是1核CPU/4G內存。memcached軟件用的是couchbase，版本是2.0.0 enterprise edition (build-1976)。memcached客戶用的是EnyimMemcached，版本是2.12。
如何確認是memcached服務器引起的？昨天17:00左右（還在訪問高峰期），只要這台memcached雲服務器一停運，問題立即消失；一啟來，問題立即出現。
這次故障與couchbase無關。依據是同樣版本的couchbase安裝到另一台雲服務器（操作系統是CentOS 6.3 64位）上，問題沒有出現。現在的memcached服務器就是這么跑的。
我們來看看應用程序中對memcached的操作情況，使用memcached的地方都是這么操作的——根據key從memcached中取數據，如果取到，直接返回；如果取不到，從數據庫中查詢，將查詢結果寫入memcached，然后返回。示例代碼如下：
var entry = _cacher.GetData(cacheKey) as BlogEntry; if (entry == null) { //從數據庫讀取 //... _cacher.Add(cacheKey, entry, 60); } return entry;
而上面代碼中 _cacher.GetData(cacheKey) 實際調用的是 Enyim.Caching.Memcache.MemcachedClient.Get() 方法。
如果這里等待時間長，會造成大量處理請求的線程阻塞在這里（堵車），造成正在處理請求的得不到響應，后續的請求沒有足夠的線程可用。
前天晚上（4月23日）我們已經采取了措施，以防這里存在可能的堵車問題，在web.config中修改了EnyimMemcached的設置，將connectionTimeout改為了1秒（默認是20秒）。
<enyim.com>
<memcached protocol="Binary">
<servers>
<add address="ip1" port="11211" />
</servers>
<socketPool minPoolSize="20" maxPoolSize="200" connectionTimeout="00:00:01" deadTimeout="00:00:02" />
</memcached>
</enyim.com>
也就是說，即使發生堵車現象，也只會等1秒，然后就繞到而行，直接去數據庫取數據。
但昨天發生故障時connectionTimeout沒起作用，說明客戶端已經正常連上了memcached服務器，問題不在客戶端。
與coubase無關，與memcached客戶端無關，那就剩下兩個懷疑對象：1. Linux操作系統（搬到阿里雲之前，我們是在Windows上跑的Memcached）；2. 虛擬機。
這時，一個故障期間的重要現象閃現在眼前——當時memcached的磁盤IO高！
memcached緩存的數據都在內存中，而且內存占用並不高，磁盤IO怎么會高？太奇怪了！
。。。
通過google搜索“memcached read timeout”，找到柳暗花明的線索——memcached timeout error because of slow response
直接看關鍵文字：
The problem seemed to boil down to the following:
vm.swappiness=60 (default) is a very bad idea, when combined
with deadline as a io scheduler....
conclusion:
if you use memcache and need high amounts of memory with
many objects, keep a look at your swap, and if there is
something in it (even 1 kb) - it might be too much.
after setting vm.swappiness to zero and paging in all swap,
the effects were gone.
登上昨天引發故障的那台memcached服務器，運行命令：
cat /proc/sys/vm/swappiness
60
輸出結果是60！磁盤IO高就是內存交換引起的！memcached堵車的原因就在這！
只要將swappiness設置為0，就能解決問題，設置方法參考：Adjust Your swappiness。
這是在去杭州的高鐵上寫博客時的意外收獲，這篇博客就寫到這，麻煩有經驗的朋友幫忙解釋一下swappiness=60為什么會引起這個問題？