MongoDB · 最佳實踐 · 短連接Auth性能優化 · 數據庫內核月報

## 問題通常我們使用MongoDB的時候，客戶端（driver）和MongoDB之間都是使用長連接，但是在某些場景下、某些driver仍然只能使用短連接進行連接，比如PHP。就在我們[阿里云數據庫MongoDB版](https://www.aliyun.com/product/mongodb/?spm=5176.7960203.201.29.kLeoev)商業化后沒多久，我們就遇到了一個用戶短連接過多導致的性能問題。這個問題的癥狀是MongoD的CPU使用率居高不下，16個核都跑滿了，影響到了用戶的正常使用。 ## 排查首先想到的當然是看看有沒有很多慢查詢，針對存在的慢查詢都建議用戶建了索引后，情況還是沒有好轉。這時我們觀察到用戶的driver不斷有短連接上來，基本上身份認證完執行個操作后很快就斷開。會不會是短連接的問題導致呢？因為[阿里云數據庫MongoDB版](https://www.aliyun.com/product/mongodb/?spm=5176.7960203.201.29.kLeoev)出于安全考慮，強制打開了身份認證，我們知道 MongoDB3.0 后使用的身份認證機制是[SCRAM-SHA1](https://yq.aliyun.com/articles/16919?spm=5176.group11.0.0.ZGL8ST)，這是需要進行一些 CPU 密集型操作比如哈希計算等的。通過profile工具進行診斷后，我們發現 CPU 熱點非常集中，主要消耗在讀取?`/dev/urandom`?來生成隨機數，這需要通過系統調用進入內核態。再結合監控，確實 CPU 都消耗在sys而不是user。以下為profile工具診斷圖： ![](https://box.kancloud.cn/2016-04-22_5719d9fee30c4.jpg) 對照一下源碼就知道了，這是因為在認證過程中需要生成一串叫做server-nonce的隨機字符串（具體的認證過程及這個隨機字符串的作用可參照[MongoDB中使用的SCRAM-SHA1認證機制](https://yq.aliyun.com/articles/16919?spm=5176.group11.0.0.ZGL8ST%EF%BC%89)。在Linux平臺下，是通過這個`/dev/urandom`（Linux上提供了兩個隨機數生成的特殊設備文件，還有一個是`/dev/random`，這兩個的區別是從`/dev/urandom`?中讀取是非阻塞的，具體可再自行google或看man手冊。）來生成隨機數的。其原理是利用當前系統的熵池來計算出一定數量的隨機比特，然后將這些比特作為字節流返回。熵池就是當前系統的環境噪音，因此其隨機效果還是比較好的。不過有利必有弊，這個`/dev/urandom`的性能就不怎么好了。要使用這個來生成隨機數，首先要進行系統調用，這涉及用戶態到內核態的切換。其次，為了避免兩個并發讀返回同樣的結果，在內核中使用了spinlock，因此在多線程并發從`/dev/urandom`中讀時，性能會急劇下降。這個東東設計之初是為了安全，而不是性能。因此建議的做法是使用`/dev/urandom`來初始化用戶態的隨機數，而不是每個請求都從這里取。 ## 解決既然知道了問題，那么解決也就好辦了，當然是想辦法使用一個性能較好，隨機性又不差的方案來替換這個`/dev/urandom`。我們使用了一個用戶態的隨機數生成器，效果非常明顯，CPU使用率從100%降到10%。以下為優化前后CPU使用率對比圖： ![](https://box.kancloud.cn/2016-04-22_5719d9ff3b2e3.jpg) 其中紅色、藍色、綠色分別為關閉Auth、打開Auth（優化前）和打開Auth（優化后）。目前[阿里云數據庫MongoDB版](https://www.aliyun.com/product/mongodb/?spm=5176.7960203.201.29.kLeoev)已經全面使用了性能優化版，所以各位使用短連接（如PHP driver）的客官們可以放心使用了。