MongoDB の チューニンガソン環境を作った。 - 中年engineerの独り言 - crumbjp
例のGoogle compute engine ６０日トライアル の$300 分をどう使おうか・・・と考えていたのだが、MongoDBのチューニンガソンに使えるんじゃないか！？と思って週末に一気に作ってみた。 mongo-tuningason.crumb.jp" いきなり超負荷を掛けると、色々問題が起きるので、Stage1 ~ 4 まで別けて、ある程度チューニングが進んでから、だんだん負荷が掛かる構造にした。 stage1 5秒以内に一連のクエリーが完了すること。プロファイルの取り方と基本的なindex知識 stage2 5秒以内に一連のクエリーが完了すること。複雑なindexが張れるか？ stage3 2~3秒の間で難易度を調整中。かなり突っ込んだindexを張れないとクリア出来ない stage4 最終ステージ。負荷が一気に増え、クリアではなくスコア（qps）での競争。MongoDB周り
MongoDB3.2 ReleaseNote所感 - 中年engineerの独り言 - crumbjp
そろそろ3.2も手を付けようと思うので、検証がてらつらつらと。。 リリースノート https://docs.mongodb.org/manual/release-notes/3.2/ 非常に丁寧な日本語訳があるので、こちらもどうぞ http://qiita.com/fetaro/items/cd570d70623b58b5deef WiredTiger as Default まあ規定路線なので、特に気にする必要なし。 Replication Election Enhancements Primaryが落ちた時の検知が早くなった。 どういうシチュエーションでどの位早くなるのかはまだ検証してない。 少なくとも今迄の落ち認定10秒をカスタマイズ可能になった。 その他色々timeout値が弄れるようになった様だが、これはまだ実験段階なんだろう。と読む事もできる。 要注目 Sharded Clust
AWS上にハイパフォーマンスMongoDBを構築する方法 - 中年engineerの独り言 - crumbjp
AWSインスタンスの選定 AWSインスタンスタイプ一覧 以下のインスタンスボリュームが付随しているプロダクトラインが候補になる。 個人的にはi2.xxx が好みである。 r3.xxx メモリ最適化インスタンス i2.xxx SSD容量最適化インスタンス ただし、インスタンスボリュームはスナップショットが取れず、揮発性なので取り回しが悪い。 Provisioned IOPS (SSD) ボリュームも検討候補になるが、高くつく事になるのでお金持ちの人用。。 バックアップ戦略 流石にバックアップを全く取らずに運用する事は出来ないので 以下様にレプリカセット構成を組み、バックアップを取る。 Primary: i2.xxx Secondary: i2.xxx Secondary(hidden): 適当なインスタンス + SSD 最後のノードはバックアップ専用なので、SSD以外は非力出よい。 ただしあ
MongoDB3系(WiredTiger)の現状 - 中年engineerの独り言 - crumbjp
ご無沙汰してます。 最近全然更新出来てない訳ですが、MongoDBに愛想が尽きて、離れていた訳ではありません。 むしろガッツリ嵌ってます。。 最近は MongoDB3 系 WiredTiger を使いながら頑張っている訳ですが・・・ キリの良い所で書こうと思っていたのに、メドが立たないので近況だけでも書いておこうかと思った次第。。 で、、mongo3... コイツすぐ落ちる！！ まあ、普通にメモリーリークですが、、ちょっと目を離すと Tasks: 169 total, 1 running, 168 sleeping, 0 stopped, 0 zombie %Cpu(s): 12.4 us, 0.7 sy, 0.0 ni, 86.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 62916396 total, 62567524 used, 3488
MongoDB 3.0 リリースノート斜め読み - 中年engineerの独り言 - crumbjp
遂にMongoDB 3.0 が正式リリースされました！！ 例によってリリースノートを斜め読みします。 http://docs.mongodb.org/master/release-notes/3.0/ が、、最初に一言で纏めると、まあ、、 目玉機能はロックレベルの話だけですよー でわ。。 Pluggable Storage Engine AP 以下の２つからストレージエンジンを選べる。 MMAPv1 これまでのストレージエンジン。デフォルト WiredTiger 3.0から追加されたストレージエンジン WiredTiger MongoDBの全ての機能をサポートしている。 MMAPv1とフォーマットが違うので既存のアップデートの場合、移行する際に色々必要。 ドライバも最新に上げないとダメ。 ドキュメントレベルロックが可能！！ touchコマンドはサポートしてない MMAPv1 Improve
Index intersection を試してみた。（失敗談） - 中年engineerの独り言 - crumbjp
MongoDB 2.6 からIndex intersectionという機能が追加された。 １つのクエリーで２つのインデックスを使う（かもしれない）機能で、より効率的にクエリーを処理できる。 （どう効率的なのか？はこのへんが詳しい） さて、じゃあ実際に見てみようというのが今回の趣旨。 元データ 国土地理院が公開している住所情報が手元にあったのでこれを使うことにした。 大体1000万件/4GB弱のデータ。 > db.block_master.stats().count 11700898 > db.block_master.stats().size 3713899792 > db.block_master.findOne() { "_id" : ObjectId("52b8378dab3de2fd4abb193f"), "full" : "北海道 札幌市中央区 南七条西十一丁目 １２８１", "
Mongoクエリー・ベース・レプリケーション - 中年engineerの独り言 - crumbjp
レプリカセット間レプリケーション MongoDBではレプリカセットを跨いでデータを同期する手段が無い。 そもそもレプリカセット自体が冗長構成を目的としているので設計に組み込まれていないのだろう。 しかし現実は Staging環境や、PV系／集計系の分離など、用途はある。 今は、レプリカセットのslaveを１台切り離してそこで何かするしかない。 フレッシュデータじゃないし運用も面倒。 monmo-repl https://github.com/monmo/monmo-repl なければ作れば良いので作った。 oplogベースの同期を行う。-s で指定したレプリカセットのPRIMARYのoplogを読み、-d で指定したレプリカセットに反映していく。 PRIMARYダウン時の挙動など、まだ未テストの部分は多いが 『とりあえず動く』 程度の完成度。 例 ReplicaSet1 =sync=> R
MongoDB 2.4 => 2.6 アップデートした - 中年engineerの独り言 - crumbjp
2.6.1(人柱バージョン)にチャレンジ 2.4.4 => 2.6.1 バージョンアップ手順 今回データファイルには互換性があるので超簡単 ディレクトリ構成 /usr/local/mongo |- bin -> mongodb-linux-x86_64-2.4.4/bin |- mongodb-linux-x86_64-2.4.4 |- data |- logs |- conf |- mongod.conf 手順 Download & extract $ cd /tmp $ wget http://fastdl.mongodb.org/linux/mongodb-linux-x86_64-2.6.1.tgz $ cd /usr/local/mongo $ tar xzvf /tmp/mongodb-linux-x86_64-2.6.1.tgz 既存のmongodを落とす $ kill `c
MongoDB2.6リリースノート斜め読み！ - 中年engineerの独り言 - crumbjp
ご存知の通りMongoDB2.6がリリースされました！ 相変わらず乱文で解説！！ Aggregation Enhancements Aggregationが強化された。 db.collection.aggregate() がカーソルを返却するようになった 今まで最終結果には64MBの制約があったが、解消されたようだ。 というかそれが普通。。。 パイプラインがexplainをサポート 今までは感覚で是非を判断していたので嬉しい改善！ ディスクソートが効率的になった $out オペレータで指定のコレクションに結果出力が可能 今までは結果をforで回して入れなおしてたのでこれも便利。 $redact でパイプライン中にデータの微修正ができる あんまり使う機会が思い当たらない。。 多分この様な用途でMongoDBを使うこと自体が詰んでる。 新しいoperator $let, $map $liter
MongoDB製JOB Queue - 中年engineerの独り言 - crumbjp
お盆が暇だったので MongoDB製Job queue を作った。 名前はMONMOちゃん。 javascriptで手軽に使いたい部分があって個人用で考えていたが 結構マトモなモノが出来上がったので公開する事にする。 またMONMOちゃんを使って、自然言語処理も一式書いてみたが こちらは次回紹介する。 注意 Javascript製ではない。 MongoDB製だ！ 繰り返し言おう。 MongoDBは環境である！！ About Monmoちゃん github https://github.com/monmo/monmo 概要 全ての処理はMongoDB(mongod) 及び Mongo shell(mongo)上で動作する。 JobはJavascriptで記述する。 MongoDBへJob投入（制御データと実装）すると、予めどこかで起動したWorkerが処理する。 Job投入側にはスクリプトを
MongoDB 2.4 の性能 徹底評価（Memory vs DISK） - 中年engineerの独り言 - crumbjp
大体欲しいデータは揃ったのと、MongoDBの気持ちが解ってきたのでMongoDB2.4の性能調査は今回で最後の予定 実は前回MongoDB 2.4 の性能 徹底評価（レコード長による評価）のFETCHバイト数（1.5GB） 実は今回のOn-memoryデータ vs DISKリードに繋げる事を意図した大きさだった。 システムの2GBメモリに収まるだろう。と・・・ しかし、、測れど測れど、意図した通りの結果にならない・・・ それで気付いた。 インデックスの大きさを勘違いしていたのだ。 MongoDBのインデックスは単なるコレクションでは無いようだ！ 1億件の数値型インデックスは2.3GBにもなる。 という訳で、1億件のコレクションのインデックスはそもそもメモリーに入らない。。 １ドキュメント辺り25〜26byte インデックス数値型８バイト＋ドキュメントへのポインタ８バイト＋メタ情報？ _i
MongoDBが適さないケース - 中年engineerの独り言 - crumbjp
> 原文(Why MongoDB is a bad choice for storing our scraped data) 私自身はMongoDBを推進する立場なのだが、確かにMongoDBに適さないケースはある。 闇雲に推進しても結局は全員がアンハッピーになるので、この様なネタもどんどん紹介していこうと思う。 この記事はMongoDBを徹底的に使い尽くしたエンジニアが書いている様で状況が良く解った。 ちょっと難しい所もあるので要点を意訳して、軽く解説を書いてみる。 （もちろん是非原文で読むのをお勧めする） 状況 最初はMongoDBでうまく動いていたが、だんだん苦労が増えてきて 元々のアーキテクチャを刷新するタイミングでMongoDBから別のプロダクトに乗り換える事にした。 システムの規模 詳しく書かれていないが、１ノード辺り数TBとあるのでSharding環境ではないかと思われる。
MongoDB 2.4 の性能 徹底評価（レコード長による評価） - 中年engineerの独り言 - crumbjp
前回のMongoDB 2.4 の性能 徹底評価の反響が大きかったので続編。 今回の調査対象 ドキュメントサイズ毎の性能を評価する。 今回の検証用にベンチを書いた。 性能見積りにも使えると思うので、紹介しておきます。 MongoDB-JP/mongo_bench 今回の検証も、Sakura VPS 2G で行った。 専用環境ではないので、ある程度まわりの影響を受けている。（何度もベンチを取って極力排除はしたが、、） また、記事に載せた以外にも色々と検証しており、その結果も少し混ざっていたり。。 オンメモリデータの処理が高速な事は解っているので 今回の検証の肝は『ディスクアクセス』 MongoDBはメモリ以上のデータを扱う為のプロダクトなのでなるべく性能が出ない様な条件＝ワーストケースを狙った。 2GBメモリに対して40GBのデータを扱い、データ全体を万遍なく使うようなクエリーを発行する。 評
/proc/[pid]/stat まとめ - 中年engineerの独り言 - crumbjp
いつも忘れるので、まとめておくことにした stat No フィールド scanf 説明 0 pid %d プロセス ID。 1 comm %s 括弧でくくられた実行形式のファイル名。実行形式がスワップアウトされているかどうかによらず、見ることができる。 2 state %c "RSDZTW" のどれか 1 文字。 R は実行中 (running)、 S は割り込み可能な休眠状態 (sleeping in an interruptible wait)、 D は割り込み不可能なディスクスリープの待機状態 (waiting in uninterruptible disk sleep)、 Z はゾンビ状態 (zombie)、 T はトレースされている (traced) か (シグナルにより) 停止している状態 (stopped)、 W はページング中 (paging) を表している。 3 ppid
![/proc/[pid]/stat まとめ - 中年engineerの独り言 - crumbjp](https://cdn-ak-scissors.b.st-hatena.com/image/square/6e8c00444c21320e56b79d3580a74c72010e2fb6/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F10328749687194688875%2F10328749687194689513%2F1479310246)
MongoDBのデータファイル同期について - 中年engineerの独り言 - crumbjp
MongoDBのストレージエンジン ココで触れた通り MongoDBは書き込みリクエストを受け付けると、一旦、内部キューにデータを積み、 バックグラウンドスレッド(journal)によって、journalファイルとデータファイルのmmap領域に書き込まれる。 その後、更にバックグラウンドスレッド(DataFileSync)によってmsync()され無事にファイルに書き込まれる事になっている。 この書き込む動作をwriteback呼ぶ しかし、Linuxでは、mmap()領域はmsync()せずともkernelが一定間隔で書き込んでくれる。 今回は、この辺の挙動の話。 MongoDBのwriteback mongodの起動オプション--syncdelay=<秒> によって指定できる。 デフォルト値は60 0を指定するとmsync()を呼ばない挙動になる。 //docs.mongodb.org
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
