Munin 2.0にLazy Load Plugin for jQueryを組み込むと快適になる話

はい、おつカレー様です。
くわのです。

Muninという監視ソフトウェアがございます。
こちら、とても使い勝手のいい、ソフトウェアでございまして、プラグインも作りやすいし便利なものなんですが、良くないのが、「1.4だと性的静的なグラフ画像生成のコストがエラい高い」「2.0だとグラフ画像生成は動的にできるけど、画面表示時にガッツリ変換するのでめちゃくちゃ遅い」っていう問題があります。

今回その辺の問題を軽減するためにLazy Load Plugin for jQueryを組み込んでみました。

Muninについて詳しく知りたい方は@zembutsu さんのSlideShareを見ていただけるとありがたいです。

Muninではじめる実践★リソース監視　-俺のサーバがこんなに重いはずがない、を乗り切るために- from Masahito Zembutsu

あと、Software Design1月号も詳しい記事があります。（こちらも@zembutsu さんの記事になります）

Software Design (ソフトウェア デザイン) 2012年 11月号 [雑誌]

というか、Muninの情報が知りたかったら@zembutsu さんをウォッチしていればよろしいｗｗｗ

Lazy Load Plugin for jQueryとは

基本的に、ブラウザでWebページが読まれた時に、そこの表示される画像はすべて読み込まれます。
ただ、Munin2.0でそれをやると、前述のとおり変換が一度に走って重くなります。
そのため、画面の表示されている範囲のみの画像だけを読み込む、というのがLazy Load Plugin for jQueryです。
詳しくは公式ページをどうぞ。

組み込み手順

まずjQuery & Lazy Load Plugin for jQueryの設置

cd /opt/munin/www/docs/static
wget http://www.appelsiini.net/projects/lazyload/jquery.lazyload.js
wget http://ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js
# 適当にdot.png作っておいとく
# wget http://example.com/dot.png

Muninのテンプレートファイルの更新

ヘッダのテンプレートファイルのバックアップ、更新

cp /etc/munin/templates/partial/head.tmpl{,.org}
vim /etc/munin/templates/partial/head.tmpl

更新内容

# diff head.tmpl.org head.tmpl
20a21,31
> <script src="<TMPL_VAR NAME="R_PATH">/static/jquery.min.js" type="text/javascript" charset="utf-8"></script>
> <script src="<TMPL_VAR NAME="R_PATH">/static/jquery.lazyload.js" type="text/javascript" charset="utf-8"></script>
> <script type="text/javascript" charset="utf-8">
>     $(function() {
>         $("img").lazyload({
>            effect      : "fadeIn"
>         });
>     });
> </script>
>
>

日時グラフ一覧画面のテンプレートファイルのバックアップ、更新

cp /etc/munin/templates/munin-comparison-day.tmpl{,.org}
vim /etc/munin/templates/munin-comparison-day.tmpl

更新内容

# diff munin-comparison-day.tmpl.org munin-comparison-day.tmpl
25c25
<                               <img src="<TMPL_VAR NAME="CIMGDAY">" alt="<TMPL_VAR ESCAPE="HTML" NAME="LABEL">"
---
>                               <img data-original="<TMPL_VAR NAME="CIMGDAY">" src="/munin2/static/dot.png" alt="<TMPL_VAR ESCAPE="HTML" NAME="LABEL">"

• munin-comparison-week.tmpl
• munin-comparison-month.tmpl
• munin-comparison-year.tmpl

にも同様に変更を行う。
これで完了。暫く待つか、su - munin --shell=/usr/bin/munin-cronで更新されるはずです。

効果

Lazy Load Plugin for jQueryがあるものと、ないもので比べて、Dayでの一括表示時の負荷が実行プロセス数、USRの値など下がっているのがわかります。

Lazy Loadなし時のvmstat

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
11  0      0 26233984 182796 4588292    0    0     0    24 4253  567 91  9  0  0  0
16  0      0 26014516 182796 4588260    0    0     0    36 4210  868 92  8  0  0  0
16  0      0 25887604 182796 4588308    0    0     0   884 4217 1073 92  8  0  0  0
22  0      0 25894436 182796 4588336    0    0     0    68 4246 1109 92  8  0  0  0
22  0      0 25707196 182796 4588380    0    0     0  2140 4267 1215 92  8  0  0  0
22  0      0 25682580 182796 4588360    0    0     0    24 4151 1238 92  9  0  0  0
22  0      0 25734408 182796 4588372    0    0     0    24 4231 1235 92  8  0  0  0
22  0      0 25916616 182796 4588392    0    0     0   704 4214 1298 92  8  0  0  0
20  0      0 25757972 182796 4588396    0    0     0    24 4096 1157 91  9  0  0  0
21  0      0 25835520 182796 4588412    0    0     0   616 4267 1299 91  9  0  0  0
22  0      0 25787280 182796 4588408    0    0     0    24 4152 1229 92  8  0  0  0
22  0      0 25688576 182796 4588440    0    0     0    12 4158 1209 91  9  0  0  0
22  0      0 25703704 182796 4588464    0    0     0   620 4269 1324 91 10  0  0  0
22  0      0 25777548 182796 4588468    0    0     0    24 4234 1338 91  9  0  0  0
22  0      0 25701164 182796 4588468    0    0     0    28 4138 1233 91  9  0  0  0
22  0      0 25700544 182796 4588476    0    0     0    12 4248 1175 92  8  0  0  0
22  0      0 25950576 182796 4588500    0    0     0    12 4218 1302 91  9  0  0  0
22  0      0 25692216 182796 4588528    0    0     0   696 4132 1158 92  8  0  0  0
22  0      0 25730104 182796 4588548    0    0     0    24 4266 1247 92  8  0  0  0
22  0      0 25738968 182796 4588560    0    0     0    24 4146 1210 91  9  0  0  0
(snip)

Lazy Loadあり時のvmstat

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 4  2      0 26504208 183016 4624264    0    0     0  3488 3263  952 30  5 26 38  0
 4  0      0 26510788 183016 4624224    0    0     0  4260 5086 1298 61 11 13 15  0
 7  0      0 26521420 183016 4624236    0    0     0   428 4687 1329 62  6 33  0  0
 2  0      0 26561380 183016 4624228    0    0     0   488 5639 1369 89  6  5  0  0
 2  1      0 26496200 183016 4624208    0    0     0  2348 3315  756 51  4 45  0  0
 2  0      0 26587484 183016 4624240    0    0     0   608 3902 1062 52  3 45  0  0
 2  1      0 26591700 183016 4624244    0    0     0  3004 4456 1174 57  3 34  6  0
 6  3      0 26543308 183016 4624264    0    0     0  8080 4062 1136 31  8 39 23  0
 2  1      0 26577060 183016 4624312    0    0     0  5640 4028 1035 48 10 19 24  0
 1  1      0 26585724 183016 4624296    0    0    16  5836 5069  991 74  6  9 11  0
 1  2      0 26568200 183016 4624280    0    0     0  6268 3157  834 27  3 40 29  0
 4  2      0 26539744 183016 4624300    0    0     0  6316 3558  799 40  2 27 30  0
 6  1      0 26317436 183016 4624296    0    0     0  6760 4136  606 62  6 21 11  0
 1  3      0 26527636 183016 4624280    0    0     0  4192 2888  499 46  5 28 21  0
 1  2      0 26562752 183016 4624304    0    0     0  4880 2920  730 32  2 30 36  0
 7  2      0 26575960 183016 4624324    0    0    40  6708 3391  841 31  2 32 35  0
 3  1      0 26498768 183016 4624696    0    0   336  9692 4706 1006 67  5 15 13  0
 2  0      0 26590476 183016 4625060    0    0   476   604 3179 1166 43  2 51  4  0
12  0      0 26278588 183016 4625732    0    0   592  1320 4674 1609 76  6 17  1  0
 2  0      0 26504304 183016 4626052    0    0   272   248 5120 1390 91  8  1  0  0
 2  0      0 26541200 183016 4626244    0    0   188   708 3616 1219 47  2 50  1  0
(snip)

まーまーいい。

画像が一度に出ない、というデメリットもありますが、表示されないよりは全然良いので多く表示されている環境では使えるかなと思います。

新装版 たのしいムーミン一家 (講談社文庫)

Software Design (ソフトウェア デザイン) 2012年 11月号 [雑誌]

ロボットクリーナーがあると掃除が捗りすぎて怖い

はい、おつカレー様です。桑野です。

掃除毎日する人ー！（シーン）
ですよね！ぼくなんかデスクが汚すぎて引越しにガテン*1依頼出しそうになったくらいですからね！

そんな僕でも今では毎日の様にリビングの掃き掃除ができるようになる10の。。。ではなく、やってもらっているわけです。ロボに。ハイテク。
というわけでご紹介。

ツカモトエイム ロボットクリーナーミニ 【手のひらサイズのコンパクトボディ】 AIM-ROB02

うちで使っている奴はこれです。
ルンバパイセンとかに比べると機能的には劣るんですが、コスパは良い感じです。

外観

こんなかんじです、結構コンパクトです。

裏側はこんな感じ。ブラシで書きだしつつ真ん中の部分から吸い込みます。

メンテナンスは上部のカバーを開けて・・・

ゴミフィルタを外して中のゴミを捨てるだけです、ただ容量が少ないので1回動かすごとにフィルタ掃除は必要ですね。
適当に30秒くらいで出来ます。

特徴

• 安い(ルンバの3分の1くらい)
• 結構取れる（髪の毛もブラシに絡めて取れるし、大抵のホコリは取れます）
• 1回の駆動時間は40〜60分です
• インテリジェンスな動きはしませんが、4種類位の動きをランダムに行う事で何と無く全体的にカバーしますw

注意

ただ、この子色々できないこともあります。

• ゴミ容量が少ない（前述）
• 細いケーブルは巻き込んで死んでいることがあります
• 段差センサーとかないので玄関まで行くと落ちて死ぬ or 脱走ごめんなさい、ありました＞＜
• 自動充電とかはないので、大体家に帰ってくるとリビングの端っことかでピーピー鳴いています

ただ、そんなちょっと至らないこの子が可愛くなってくるわけですね！
「ははは、こやつめ」
「またこんな所で死んでやがってー」
などと一人でつぶやいている図はとても気持ち悪い事でしょう。

というわけで

広い部屋はルンバパイセンとかのがいいかもしれないですが、あまり広くない（1LDKくらい）の総フローリングの部屋とかであればこれでも十分かなと思います！

ツカモトエイム ロボットクリーナーミニ 【手のひらサイズのコンパクトボディ】 AIM-ROB02

[asin:B000VPNR4K:detail]

*1:DC作業

シェルスクリプトでパイプを使った時の戻り値のとり方

はい、おつカレー様です。
bashを使ったシェルスクリプトでパイプを使っても戻り値をちゃんと取りたいときの話です。

シェルスクリプトの戻り値

シェルスクリプトでの戻り値取るときに $? を使うことがあると思います。

$ ls /                    # こっちは正常
$ echo $?
0
$ ls /notfounddir  # こっちはエラー
$ echo $?
1

コマンドのログを取りたいなと思ってteeとかつなげちゃうとteeの戻り値になっちゃって取れないですよね。

$ ls /notfounddir | tee test
ls: /notfounddir: No such file or directory
$ echo $?　
0                # <-アレ？

${PIPESTATUS[@]}

こういう場合は、${PIPESTATUS[@]}を使うことで取ることができます。

$ ls / | tee test.log
$ echo ${PIPESTATUS[@]}
0 0
$ ls /notfounddir | tee test.log
ls: /notfounddir: No such file or directory
$ echo ${PIPESTATUS[@]}
1 0
$ echo ${PIPESTATUS[0]}
1

というわけです、便利ですねー。
こういう場合は良くあって、最初気づかなくて後で困ることも良くあるので、使ってみてくださいね(╹◡╹)

補足

他にも内部変数は幾つかあるので、このへんを見ると役に立つものがあるかも
http://tldp.org/LDP/abs/html/internalvariables.html

［改訂新版］ シェルスクリプト基本リファレンス　　??#!/bin/shで、ここまでできる (WEB+DB PRESS plus)

「MongoDBのはじめての運用テキスト」を書いてみた

MongoDB使いましょって時に、やれ、レプリカセットだの、シャーディングだの、いちいち手順とか教えていくのがめんどくさくなったので、これを見たらコマンド的な手順はひと通りいけますよ。だから後は自分で調べてね、っていう資料をつくってみたのだ。

というわけで、「MongoDBのはじめての運用テキスト」SlideShareにあげました。

MongoDBのはじめての運用テキスト from Akihiro Kuwano

内容

PDFには、以下の様な内容を盛り込んでいます。

• インストール
• レプリカセット構築
• シャーディング設定
• 基本的なオペレーション
• Stat系ツールの見方。

ただし、徐々に古い情報にはなってくると思うので、詳しい情報や、最新の情報を見たい方には公式のWikiなり、ソースなり見ていただくのを推奨いたしますｗ

意図

以前MongoDBの薄い本などもあって、あれはすごくわかりやすい入門テキストなんですが（とても参考になりました）、ちょっと開発向きなので、サーバ運用側の目線の資料が欲しかったのと、インストールからひと通り構築するまでの手順がまとまっていなくて、公式DocみたりぐぐってWeb漁ったりというのが結構めんどくさかったので一回スナップショットとってまとめとこって気持ちです。
あと、、、今出さないと公開するタイミングがなくなりそうなので、、、（ﾎﾞｿｯ

もし

なにかこれは違うとか、これはこうだって言うのがありましたら修正するので @kuwa_twまで頂けるとありがたいです。

あ（追記）

おつカレー様ですって言うの忘れてた。

[asin:B00A1R2ADW:detail]

デルモンテ マンゴー20% 750ml×6本

MongoDBイン・アクション

mac osx で bashの補完機能を有効にした話(homebrew経由)

はい、おつカレー様です。くわのです。
作業環境がMacになってきたのでその辺忘れないように書くなり。

みんなzshだzshだとかいうんですが、まあ色々覚えるのめんどくさくてｗ
zshってどんだけ便利なのか説教してくれる人を募集しています。

とりあえずbashでも補完機能あるので、これでいってみましょ。

homebrewインストール

homebrewは様々なパッケージを簡単にインストールできるやつです。
今ならmacportsはプークスクスらしいのでhomebrewのビックウェーブに乗ります。

mkdir ~/homebrew
curl -L https://github.com/mxcl/homebrew/tarball/master | tar xz --strip 1 -C ~/homebrew

終わり。

bash 補完のインストール

homebrewでbash_completionとして提供されているので、これをインストール

まず、homebrewの実行ファイルのあるディレクトリにパスを通します。

export PATH=$PATH:~/homebrew/bin

次に、bash_completionパッケージのインストール

brew install bash_completion

bashの設定

最後に、.bashrcとか、.bash_profileなどのbashの設定ファイルに補完機能を使うように設定します。

cat <<'EOF' >> ~/.bashrc
# env
export PATH=$PATH:~/bin:~/homebrew/bin
export EDITOR=vim

# tmux
alias tmux='tmuxx'
alias ls="ls -Fal"

# bash-completion
if [ -f ~/homebrew/etc/bash_completion ]; then
    . ~/homebrew/etc/bash_completion
fi
EOF

cp ~/.bashrc ~/.bash_profile

はい、以上！
これだけでも、ssh時のhostsの設定とかイチイチいらなくなるので楽ですね。

男性用　お洒落作務衣パンツ　2色 (M, グレー)

『Mapion・日本一の地図システムの作り方』を読みました

はい、おつカレー様です。くわのです。
最近誕生日を迎えまして、誕生日プレゼントがみんなカレーにちなんだもので、おいらのカレーブランディングはもう揺るがないのだなと思う毎日です。
毎日カレー食べます。た、食べますよ！

技術評論社さんから『Mapion・日本一の地図システムの作り方』を献本いただきました！いつもありがとうございます！

そこで、早速読んでみたのですが、奥さん僕が言いたいのはこの本から伝わってくる熱気というか、本気度合いが凄いなと。いうことなんですよ。
この本書くの大変だっただろうな、と言う雰囲気が伝わってくる本です。

Mapion・日本一の地図システムの作り方 (Software Design plus)

内容

インフラをやっている身なので、主にインフラの章を読んだ（アプリのお話もあります）のですが、この本で特徴的なのは、
○○の使い方、とか、○○をやるためにはみたいな本じゃない所ですね。もちろんそういう本も大事だし、面白いんですが。
ただ、この本はどっちかというと、Mapionさんのシステムの歴史を泥臭く、泥臭く書いた本で、ある意味手記と言ってもいいんじゃないでしょうかｗ

興味深く、面白かったです。
地図システムのGEO系の検索エンジン等に関わりのある方には当然ながら素晴らしいノウハウの詰まった本なのですが、通常のWebシステムを作っている限りはあまり縁がない人も多いと思います。
そういう点において、ああ、じゃあおいらには縁のない本だ（ﾍﾍｰﾝ）とするにはもったいないなぁと。

例えば、Mapionさんで現在地図のGEO系の検索にはSolrを使っていると言うことで、この本にもSolrの話がたくさん出てくるのですが、例えば、Solrでトラブった話では○○という理由のために動かなくて、☓☓という作戦に変更した、とか。
まだ問題が解決していないけど過程として△△という事もやったけど、根本解決に至らなかったよという事をキチンと書いていたりとか。中々読み物として面白いのです。
「月曜10時問題との戦い」って章があるんですが、よくありますよね、この時間になるとおかしくなるみたいな奴。これの対応を一歩一歩している過程を書いていたりとか、あーそれそれーあるよねーとか。
とにかくぶっちゃけている。インフラの章ｗ
なんかMapionさんのインフラ大解剖といった面持ちで、へー。へー。って言いながら読みました。

それでいいところは、考え方の道筋がわかるという所です。
まず問題があって、それを対処するために、これを試していった、根本的ではなかったから次はこういう理由でこれを試した、という切り分けの流れですね。
こういう知識って最初から手に入るものではなくて、色々経験して手に入れるものなので、その知識はただこうしたらできるよ、って言う物とはまた違った知識なので、そういうものを惜しげもなく公開しているのが凄いし、まとめるのが大変だっただろうなと思いました。

個人的に、昔書いた本がそのような泥臭い本だった気がしていてデジャヴだったというのもあるわけで、一緒にお酒でも飲みたいなと思うわけですｗ
、、、閑話休題(； ･`д･´)

というわけで

GEO系のシステムの作り方を知りたい人はもちろんですが、先ほど話しにでた、Solrの運用話や、Javaアプリケーション、Tomcatの運用や、どのようにアプリケーション／インフラ運用をしていくか、スモールスタートから大きくなっていくシステムとはこういうものだ、という様々な事を知る、解決するためのヒントにもなるのではないかと思います。
お酒飲みましょうお酒（またか

というのはともかく、ご興味があればお手にとっていただければと思います。

Mapion・日本一の地図システムの作り方 (Software Design plus)

チーズ事典―家庭で本格的に楽しめる、ナチュラルチーズのすべて

MongoDBでChunkのMigrationが進行中か確認したい場合

MongoDBのAutoBalancingって便利ですよね。

便利というか、手動Balancingが即時全体反映じゃないので、AutoBalancing使わざるを得ない理由もありますが(； ･`д･´)

というわけで、今Shard間でChunkのMigration(以下moveChunk)が走っていないか確認する方法です。
小ネタ注意報。

configデータベース

mongocに入っているconfigデータベースには各種Shardingに関する情報が入っています。
これらのCollectionを見ることで現在のShardingの情報は大体わかります。

スキーマの概要はここ

changelogコレクション

Splitとか、moveChunkが走っているかを見たいのであれば、changelogコレクションを見ましょう。
ここにSplitや、moveChunk等のイベントの進行状況がわかるようになっています。
デフォルトでは10MのCappedCollectionです。

見方

$ /usr/local/mongodb2_1/bin/mongo # mongocにつなぐ
> use config
> db.changelog.find()
(snip)
{ "_id" : "mongotest-25-2011-10-17T23:35:25-118", "server" : "mongotest-25", "clientAddr" : "192.168.0.150:56639", "time" : ISODate("2011-10-17T23:35:25.635Z"), "what" : "moveChunk.from", "ns" : "testdatabase.testcollection", "details" : { "min" : { "_id" : "742e4aeaf3f1806b" }, "max" : { "_id" : "74fa5d10c4e68473" }, "step1" : 0, "step2" : 7, "note" : "aborted" } }
{ "_id" : "mongotest-25-2011-10-17T23:35:25-119", "server" : "mongotest-25", "clientAddr" : "192.168.0.150:56639", "time" : ISODate("2011-10-17T23:35:25.666Z"), "what" : "split", "ns" : "testdatabase.testcollection", "details" : { "before" : { "min" : { "_id" : "742e4aeaf3f1806b" }, "max" : { "_id" : "74fa5d10c4e68473" }, "lastmod" : { "t" : 203000, "i" : 1 } }, "left" : { "min" : { "_id" : "742e4aeaf3f1806b" }, "max" : { "_id" : "7496a0fb2877cf18" }, "lastmod" : { "t" : 222000, "i" : 2 } }, "right" : { "min" : { "_id" : "7496a0fb2877cf18" }, "max" : { "_id" : "74fa5d10c4e68473" }, "lastmod" : { "t" : 222000, "i" : 3 } } } }
{ "_id" : "mongotest-25-2011-10-17T23:35:41-120", "server" : "mongotest-25", "clientAddr" : "192.168.0.150:56639", "time" : ISODate("2011-10-17T23:35:41.690Z"), "what" : "moveChunk.start", "ns" : "testdatabase.testcollection", "details" : { "min" : { "_id" : "742e4aeaf3f1806b" }, "max" : { "_id" : "7496a0fb2877cf18" }, "from" : "ShardTest025", "to" : "ShardTest030" } }
{ "_id" : "mongotest-30-2011-10-17T23:35:42-29", "server" : "mongotest-30", "clientAddr" : "(NONE)", "time" : ISODate("2011-10-17T23:35:42.706Z"), "what" : "moveChunk.to", "ns" : "testdatabase.testcollection", "details" : { "min" : { "_id" : "742e4aeaf3f1806b" }, "max" : { "_id" : "7496a0fb2877cf18" }, "step1" : 3, "step2" : 0, "step3" : 817, "step4" : 0, "step5" : 188 } }
{ "_id" : "mongotest-25-2011-10-17T23:35:42-121", "server" : "mongotest-25", "clientAddr" : "192.168.0.150:56639", "time" : ISODate("2011-10-17T23:35:42.710Z"), "what" : "moveChunk.commit", "ns" : "testdatabase.testcollection", "details" : { "min" : { "_id" : "742e4aeaf3f1806b" }, "max" : { "_id" : "7496a0fb2877cf18" }, "from" : "ShardTest025", "to" : "ShardTest030" } }
{ "_id" : "mongotest-25-2011-10-17T23:35:42-122", "server" : "mongotest-25", "clientAddr" : "192.168.0.150:56639", "time" : ISODate("2011-10-17T23:35:42.917Z"), "what" : "moveChunk.from", "ns" : "testdatabase.testcollection", "details" : { "min" : { "_id" : "742e4aeaf3f1806b" }, "max" : { "_id" : "7496a0fb2877cf18" }, "step1" : 0, "step2" : 6, "step3" : 2, "step4" : 1001, "step5" : 15, "step6" : 201 } }

splitの場合

{ "_id" : "mongotest-25-2011-10-17T23:35:25-119", "server" : "mongotest-25", "clientAddr" : "192.168.0.150:56639", "time" : ISODate("2011-10-17T23:35:25.666Z"), "what" : "split", "ns" : "testdatabase.testcollection", "details" : { "before" : { "min" : { "_id" : "742e4aeaf3f1806b" }, "max" : { "_id" : "74fa5d10c4e68473" }, "lastmod" : { "t" : 203000, "i" : 1 } }, "left" : { "min" : { "_id" : "742e4aeaf3f1806b" }, "max" : { "_id" : "7496a0fb2877cf18" }, "lastmod" : { "t" : 222000, "i" : 2 } }, "right" : { "min" : { "_id" : "7496a0fb2877cf18" }, "max" : { "_id" : "74fa5d10c4e68473" }, "lastmod" : { "t" : 222000, "i" : 3 } } } }

split表示が出ていれば、そのタイミングでデータのsplitが実行されたということです。

moveChunkの場合

{ "_id" : "mongotest-25-2011-10-17T23:35:41-120", "server" : "mongotest-25", "clientAddr" : "192.168.0.150:56639", "time" : ISODate("2011-10-17T23:35:41.690Z"), "what" : "moveChunk.start", "ns" : "testdatabase.testcollection", "details" : { "min" : { "_id" : "742e4aeaf3f1806b" }, "max" : { "_id" : "7496a0fb2877cf18" }, "from" : "ShardTest025", "to" : "ShardTest030" } }
{ "_id" : "mongotest-30-2011-10-17T23:35:42-29", "server" : "mongotest-30", "clientAddr" : "(NONE)", "time" : ISODate("2011-10-17T23:35:42.706Z"), "what" : "moveChunk.to", "ns" : "testdatabase.testcollection", "details" : { "min" : { "_id" : "742e4aeaf3f1806b" }, "max" : { "_id" : "7496a0fb2877cf18" }, "step1" : 3, "step2" : 0, "step3" : 817, "step4" : 0, "step5" : 188 } }
{ "_id" : "mongotest-25-2011-10-17T23:35:42-121", "server" : "mongotest-25", "clientAddr" : "192.168.0.150:56639", "time" : ISODate("2011-10-17T23:35:42.710Z"), "what" : "moveChunk.commit", "ns" : "testdatabase.testcollection", "details" : { "min" : { "_id" : "742e4aeaf3f1806b" }, "max" : { "_id" : "7496a0fb2877cf18" }, "from" : "ShardTest025", "to" : "ShardTest030" } }
{ "_id" : "mongotest-25-2011-10-17T23:35:42-122", "server" : "mongotest-25", "clientAddr" : "192.168.0.150:56639", "time" : ISODate("2011-10-17T23:35:42.917Z"), "what" : "moveChunk.from", "ns" : "testdatabase.testcollection", "details" : { "min" : { "_id" : "742e4aeaf3f1806b" }, "max" : { "_id" : "7496a0fb2877cf18" }, "step1" : 0, "step2" : 6, "step3" : 2, "step4" : 1001, "step5" : 15, "step6" : 201 } }

moveChunkの簡単な動き

moveChunkは以下の様な手順で行われます。
ソースで言うと、mongo/s/d_migrate.cpp になります。(これは2.0系のソース)

1. オプション解析
2. 分散ロック
3. moveChunk開始　読み取りロックかけながら、徐々にデータ転送するため全ソートデータとディスクロックをかける
4. データ転送が終わるまで停止
5. ロック configサーバロックして、migrateが終わったらconfigサーバアップデートして、changelogコレクションの更新
6. 転送元のCursorが期限切れになるのを待つ
7. 元データ削除

changelogコレクションでの表示

これはwhatの項目で示されていますが、以下の順番でステータスが変わっていきます。
moveChunk.start -> moveChunk.to -> moveChunk.commit -> moveChunk.from
moveChunk.from まで終われば、元データの削除まで終わり、moveChunkは終了していると見て問題ありません。

MongoDB in Action