crumbjpLinuxとApacheの憂鬱この広告は、90日以上更新していないブログに表示しています。AnalyzerMongoDB2.4からはサーバリソースの管理・評価にAnalyzerが使えるようになりました。利用方法は既存のコマンドdb.serverStatus()を叩くだけです。workingSet項目の出力はserverStatusにworkingSetパラメータを明示的に指定した場合に出力されます。MongoDBが現在利用しているデータ量などワーキングセットサイズの見積もりに利用できる情報を含むドキュメントです。workingSetはmongodが利用しているアクセスページ追跡用の内部データです。workingSetドキュメントが見積もりに過ぎないという警告メッセージです。set.serverStatus.workingSet.pagesInMemoryはmongodがoverSecondsフィールドが示す秒数間にアクセスしたページの総数です。ページサイズはデフォルト4KBでページ数×4KBでデータ量になります。総ワーキングセットサイズがサーバの物理メモリ量を下回った場合、pageInMemoryの値は扱っている(あなたの)データ量を示すだろう。逆に扱っているデータ量が物理メモリサイズを超えた場合、この値は物理メモリ量を示すだろう。実際のワーキングセットサイズを見積もる為にpageInMemoryとoverSecondsを使ってください。workingSet.serverStatus.workingSet.computationTimeMicroscomputationTimeMicrosはmongodがworkingSetドキュメントを算出するのに掛った時間です。workingSetレポートを作る処理はmongodのパフォーマンスに影響を与え得る。それはMongoDBはコンテキストをロックしてデータを収集しなければならないからだ。頻繁にworkingSet情報を監視しようとする自動モニタリングツールはこの事を考慮する事。RAM.serverStatus.workingSet.overSecondsoverSecondsはpageInMemoryに含まれる最古のページと最新のページの差(つまりpageInMoeoryカウント期間)である。overSecondsが減少するかpagesInMemoryがサーバ物理メモリ量と等しくoverSecondsが非常に小さい場合、ワーキングセットサイズは物理メモリ量よりずっと大きい(つまりメモリーが足りない)事を意味する。overSecondsが大きい場合、MongoDBのデータセットは物理メモリ量以下である。実際の評価方法まずはメモリー情報を取る。:物理メモリーは487MBです。10524}resident実際占有しているメモリー(MB)つまり127MBのメモリーを使っているvirtual仮想メモリーとして取得しているサイズ(MB)つまり11GB程度。mappedデータファイルのマッピング量(MB)mmapで5GB程度マップしている。mappedWithJournaljournalも含んだマッピング量いつもmappedの倍になる。いう事でmongodは127MBのメモリーを使っている様です。ここでマッピングファイルが10GBあるのにメモリー127MBじゃ全然足りないじゃん!というのは早計です。1189}pageInMemory約448MBoverSeconds約20分そんな訳でpageInMemoryは物理メモリー量に近い反面、overSecondsは十分長い。メモリーに載り切らない程のデータを扱ってはいるものの、アクセス頻度はそれ程でも無くメモリー不足が逼迫している程でもない。MongoDBは解釈しているが127MB以外はOSによってスワップアウトされておりやっぱりメモリーが足りてない!OSで別に動いてるプロセスを止めるかメモリーを足すべきと解釈できます。追記アクセス量を増やした所、こうなりました。925}pageInMemory約597MBoverSeconds約15分overSecondsは減りましたね。充分な負荷やバラツキが再現できていないのか思ったより減りません。今時、digest認証なんかしたくないんだが。クエリーITシステムを構築するということ月別アーカイブはてなブログをはじめよう!hiropponさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。