【原創】使用者空間死循環導緻memcached通路變慢問題排查

有同僚發現，某業務通路 memcached 時，時不時查詢速度會變慢，正常情況 幾十毫秒 ，而慢的時候會達到 幾百毫秒 。該同僚百思不得其解，以為 memcached 出了什麼奇怪的問題。 

拿到問題後，簡單思考一些，給出如下問題排查思路： 

memcached 是基于 libevent 實作的多線程服務程式，理論上講能夠輕松應對大量連接配接通路；

業務通路模型比較簡單，沒有複雜的使用場景，且通路速度變慢是随機發生的，并沒有什麼規律；

是以我的最終結論，懷疑是否由其他業務的運作情況異常，導緻目前業務針對 memcached 的通路變慢。 

按照這個思路，首先 檢視 memcached 實時運作情況，可以看到 memcached 啟動了 6 個線程在跑，6 個線程分布（運作）在 5 個 cpu 上。 

在如下輸出資訊中，可以看到有幾個 cpu 使用比較高，達到了 50% 以上。 

重新執行 top 觀察是否其他程序存在異常，結果發現名為 sus 的程序 cpu 占用達到 100% 。 檢視其對應的線程運作情況如下 

另外一次 top 輸出可以清楚看到其中一個 cpu 被跑滿。 

檢視占用 cpu 100% 的線程的運作狀态，發現一直處于析構函數的執行中。 

觀察線程 23805 的運作時狀态資訊，可以看到 nonvoluntary_ctxt_switches 的值一直在快速增長，對比 strace -p 23805 沒有任何輸出，進一步說明該線程處于使用者态死循環中。 

下面給出一個 memcached 和死循環業務跑才同一個 cpu 的資訊輸出 

可以看到死循環線程跑在了 cpu1 上。 

與此同時，memcached 其中一個線程也跑在了 cpu1 上，是以，若此時業務請求恰好被該線程處理，則會出現處理速度變慢的問題。 

到此，問題基本上清楚，在将問題業務處理掉後，memcached 又和從前一般快了~~