記一次MongoDB性能問題，附原理解析
下面文章轉載自火丁筆記，原作者描述了一次MongoDB數(shù)據(jù)遷移過程中遇到的性能問題及其解決方案，中間追查問題的方法和工具值得我們學習。
下面是其原文：
最近忙著把一個項目從MySQL遷移到MongoDB，在導入舊數(shù)據(jù)的過程中，遇到了些許波折，犯了不少錯誤，但同時也學到了不少知識，遂記錄下來。
公司為這個項目專門配備了幾臺高性能務器，清一色的雙路四核超線程CPU，外加32G內存，運維人員安裝好MongoDB后，就輪到我了，我習慣于在使用新服務器前先看看相關日志，了解一下基本情況，當我瀏覽MongoDB日志時，發(fā)現(xiàn)一些警告信息：
當時我并不太清楚NUMA是什么東西，所以沒有處理，只是把問題報告給了運維人員，事實證明運維人員也沒有處理，所以問題的序幕就這樣拉開了…
- WARNING: You are running on a NUMA machine.
- We suggest launching mongod like this to avoid performance problems:
- numactl --interleave=all mongod [other options]
遷移工作首先要導入舊數(shù)據(jù)。開始一切倒還正常，不過幾小時之后，我無意中發(fā)現(xiàn)不知道什么時候開始數(shù)據(jù)導入的速度下降了，同時我的PHP腳本開始不停的拋出異常：
- cursor timed out (timeout: 30000, time left: 0:0, status: 0)
我一時判斷不出問題所在，想想先在PHP腳本里加大Timeout的值應付一下：
- MongoCursor::$timeout = -1;
可惜這樣并沒有解決問題，錯誤反倒變著花樣的出現(xiàn)了：
無奈之下用strace跟蹤了一下PHP腳本：
- max number of retries exhausted, couldn't send query
- couldn't send query: Broken pipe
- shell> strace -p
發(fā)現(xiàn)進程卡在了recvfrom操作上：
- recvfrom(,
通過如下命令查詢recvfrom操作的含義是：receive a message from a socket
- shell> apropos recvfrom
還可以按照下面的方式確認一下：
此時查詢MongoDB當前操作，發(fā)現(xiàn)幾乎每個操作會消耗大量的時間：
- shell> lsof -p
- shell> ls -l /proc//fd/
- shell> echo "db.currentOp()" | /path/to/mongo
同時運行mongostat顯示很高的locked值。
…
重復做了很多工作，但始終無法找到問題的癥結在哪里，只好求助官方論壇，那里的技術支持都很熱心，在我描述了問題后，沒過多久就有了回復，建議我檢查一下是不是索引不佳所致，為了驗證這種可能，我激活了Profiler記錄慢操作：
不過結果顯示基本都是insert操作(因為我是導入數(shù)據(jù)為主)，本身就不需要索引：
- mongo> use
- mongo> db.setProfilingLevel(1);
問 題到了這里，似乎已經(jīng)走投無路了，為了死馬當活馬醫(yī)，我又重復了幾次遷移舊數(shù)據(jù)的過程，結果自然是次次都出問題，但幸運的是我發(fā)現(xiàn)每當出問題的時候，在 top命令的結果中，總有一個名叫irqbalance的進程居高不下，搜索了一下，結果很多介紹irqbalance的文章中都提及了NUMA，讓我一 下子記起之前在日志中看到的警告信息，于是乎按照信息里介紹的，重新啟動了一下MongoDB：
- mongo> use
- mongo> db.system.profile.find().sort({$natural:-1})
- …
- shell> numactl --interleave=all /path/to/mongod
一切都正常了。為了解決這個問題，浪費了很多精神，實在沒有力氣再解釋NUMA到底是什么東西了，有想了解的網(wǎng)友可以參考老外的文章，里面的介紹很翔實。
對于罪魁禍首，作者留給大家去學習，在這里可以給大家做一個簡單的描述，先解釋幾個概念
NUMA：NUMA是多核心CPU架構中的一種，其全稱為Non-Uniform Memory Access，簡單來說就是在多核心CPU中，機器的物理內存是分配給各個核的，架構簡圖如下所示：
每個核訪問分配給自己的內存會比訪問分配給其它核的內存要快，有下面幾種訪問控制策略：
- 1.缺省(default)：總是在本地節(jié)點分配(分配在當前進程運行的節(jié)點上);
- 2.綁定(bind)：強制分配到指定節(jié)點上;
- 3.交叉(interleave)：在所有節(jié)點或者指定的節(jié)點上交織分配;
- 4.優(yōu)先(preferred)：在指定節(jié)點上分配，失敗則在其他節(jié)點上分配。
上面文章中最后使用numactl –interleave命令就是指定其為交叉共享模式。
irqbalance：這是作者在上面提到的一個占用CPU的進程，這個進程的作用是在多核心CPU的操作系統(tǒng)中，分配系統(tǒng)中斷信號的。參見：irqbalance.org
概念說完了，下面是上面問題的簡單描述：
我們知道虛擬內存機制是通過一個中斷信號來通過進行內存swap的，所以這個irqbalance進程忙，是一個危險信號，在這里是由于在進行頻繁的內存交換。這種頻繁交換現(xiàn)象稱為swap insanity，在MySQL中經(jīng)常提到，也就是在NUMA框架中，采用不合適的策略，導致核心只能從指定內存塊節(jié)點上分配內存，即使總內存還有富余，也會由于當前節(jié)點內存不足時產生大量的swap操作。
【編輯推薦】
