公司為這個(gè)項(xiàng)目專門配備了幾臺(tái)高性能務(wù)器，清一色的雙路四核超線程CPU，外加32G內(nèi)存，運(yùn)維人員安裝好MongoDB后，就交我手里了，我習(xí)慣于在使用新服務(wù)器前先看看相關(guān)日志，了解一下基本情況，當(dāng)我瀏覽MongoDB日志時(shí)，發(fā)現(xiàn)一些警告信息：

WARNING: You are running on a NUMA machine. We suggest launching mongod like this to avoid performance problems: numactl –interleave=all mongod [other options]

當(dāng)時(shí)我并不太清楚NUMA是什么東西，所以沒有處理，只是把問題反饋給了運(yùn)維人員，后來知道運(yùn)維人員也沒有理會(huì)這茬兒，所以問題的序幕就這樣拉開了。

遷移工作需要導(dǎo)入舊數(shù)據(jù)。MongoDB本身有一個(gè)mongoimport工具可供使用，不過它只接受json、csv等格式的源文件，不適合我的需求，所以我沒用，而是用PHP寫了一個(gè)腳本，平穩(wěn)運(yùn)行了一段時(shí)間后，我發(fā)現(xiàn)數(shù)據(jù)導(dǎo)入的速度下降了，同時(shí)PHP拋出異常：

cursor timed out (timeout: 30000, time left: 0:0, status: 0)

我一時(shí)判斷不出問題所在，想想先在PHP腳本里加大Timeout的值應(yīng)付一下：

<?php
MongoCursor::$timeout = -1;
?>

可惜這樣并沒有解決問題，錯(cuò)誤反倒變著花樣的出現(xiàn)了：

max number of retries exhausted, couldn't send query, couldn't send query: Broken pipe

接著使用strace跟蹤了一下PHP腳本，發(fā)現(xiàn)進(jìn)程卡在了recvfrom操作上：

shell> strace -f -r -p <PID>
recvfrom(<FD>,

通過如下命令查詢r(jià)ecvfrom操作的含義：

shell> apropos recvfrom
receive a message from a socket

或者按照下面的方式確認(rèn)一下：

shell> lsof -p <PID>
shell> ls -l /proc/<PID>/fd/<FD>

此時(shí)如果查詢MongoDB的當(dāng)前操作，會(huì)發(fā)現(xiàn)幾乎每個(gè)操作會(huì)消耗大量的時(shí)間：

mongo> db.currentOp()

與此同時(shí)，運(yùn)行mongostat的話，結(jié)果會(huì)顯示很高的locked值。

…

我在網(wǎng)絡(luò)上找到一篇：MongoDB Pre-Splitting for Faster Data Loading and Importing，看上去和我的問題很類似，不過他的問題實(shí)質(zhì)是由于自動(dòng)分片導(dǎo)致數(shù)據(jù)遷移所致，解決方法是使用手動(dòng)分片，而我并沒有使用自動(dòng)分片，自然不是這個(gè)原因。

…

詢問了幾個(gè)朋友，有人反映曾遇到過類似的問題，在他的場景里，問題的主要原因是系統(tǒng)IO操作繁忙時(shí)，數(shù)據(jù)文件預(yù)分配堵塞了其它操作，從而導(dǎo)致雪崩效應(yīng)。

為了驗(yàn)證這種可能，我搜索了一下MongoDB日志：

shell> grep FileAllocator /path/to/log
[FileAllocator] allocating new datafile ... filling with zeroes...
[FileAllocator] done allocating datafile ... took ... secs

我使用的文件系統(tǒng)是ext4（xfs也不錯(cuò) ），創(chuàng)建數(shù)據(jù)文件非?？?，所以不是這個(gè)原因，但如果有人使用ext3，可能會(huì)遇到這類問題，所以還是大概介紹一下如何解決：

MongoDB按需自動(dòng)生成數(shù)據(jù)文件：先是<DB>.0，大小是64M，然后是<DB>.1，大小翻番到128M，到了<DB>.5，大小翻番到2G，其后的數(shù)據(jù)文件就保持在2G大小。為了避免可能出現(xiàn)的問題，可以采用事先手動(dòng)創(chuàng)建數(shù)據(jù)文件的策略：

#!/bin/sh

DB_NAME=$1

cd /path/to/$DB_NAME

for INDEX_NUMBER in {5..50}; do
  FILE_NAME=$DB_NAME.$INDEX_NUMBER

  if [ ! -e $FILE_NAME ]; then
    head -c 2146435072 /dev/zero > $FILE_NAME
  fi
done

注：數(shù)值2146435072并不是標(biāo)準(zhǔn)的2G，這是INT整數(shù)范圍決定的。

…

最后一個(gè)求助方式就是官方論壇了，那里的國際友人建議我檢查一下是不是索引不佳所致，死馬當(dāng)活馬醫(yī)，我激活了Profiler記錄慢操作：

mongo> use <DB>
mongo> db.setProfilingLevel(1);

不過結(jié)果顯示基本都是insert操作（因?yàn)槲沂菍?dǎo)入數(shù)據(jù)為主），本身就不需要索引：

mongo> use <DB>
mongo> db.system.profile.find().sort({$natural:-1})

…

問題始終沒有得到解決，求人不如求己，我又重復(fù)了幾次遷移舊數(shù)據(jù)的過程，結(jié)果自然還是老樣子，但我發(fā)現(xiàn)每當(dāng)出問題的時(shí)候，總有一個(gè)名叫irqbalance的進(jìn)程CPU占用率居高不下，搜索了一下，發(fā)現(xiàn)很多介紹irqbalance的文章中都提及了NUMA，讓我一下子想起之前在日志中看到的警告信息，我勒個(gè)去，竟然繞了這么大一個(gè)圈圈！安下心來仔細(xì)翻閱文檔，發(fā)現(xiàn)官方其實(shí)已經(jīng)有了相關(guān)介紹，按如下設(shè)置搞定：

shell> echo 0 > /proc/sys/vm/zone_reclaim_mode
shell> numactl --interleave=all mongod [options]

關(guān)于zone_reclaim_mode內(nèi)核參數(shù)的說明，可以參考官方文檔。

注：從MongoDB1.9.2開始：MongoDB會(huì)在啟動(dòng)時(shí)自動(dòng)設(shè)置zone_reclaim_mode。

至于NUMA的含義，簡單點(diǎn)說，在有多個(gè)物理CPU的架構(gòu)下，NUMA把內(nèi)存分為本地和遠(yuǎn)程，每個(gè)物理CPU都有屬于自己的本地內(nèi)存，訪問本地內(nèi)存速度快于訪問遠(yuǎn)程內(nèi)存，缺省情況下，每個(gè)物理CPU只能訪問屬于自己的本地內(nèi)存。對(duì)于MongoDB這種需要大內(nèi)存的服務(wù)來說就可能造成內(nèi)存不足，NUMA的詳細(xì)介紹，可以參考老外的文章。

理論上，MySQL、Redis、Memcached等等都可能會(huì)受到NUMA的影響，需要留意。

最新評(píng)論