非常に低いロック % ですが、mongostat の出力に膨大な (~200++) フォルト/秒の数値が表示されます。
私の Mongo サーバーは、Amazon クラウドの m1.large インスタンスで実行されているため、それぞれに 7.5 GB の RAM があります::
root:~# free -tm
total used free shared buffers cached
Mem: 7700 7654 45 0 0 6848
明らかに、モンゴがやりたいすべてのキャッシュに十分なメモリがありません (ところで、ディスク IO が原因で CPU 使用率が非常に高くなります)。
私のシナリオ (高障害、低ロック %) では、「読み取りのスケールアウト」と「より多くのディスク IOPS」が必要であることを示唆するこのドキュメントを見つけました。
これをどのように達成するのが最善かについてのアドバイスを探しています。つまり、node.js アプリケーションによって実行される可能性のあるさまざまなクエリがたくさんあり、ボトルネックがどこで発生しているのかわかりません。もちろん、試してみました
db.setProfilingLevel(1);
ただし、出力された統計には遅いクエリが表示されるだけなので、これはあまり役に立ちませんが、どのクエリがページフォールトを引き起こしているかをその情報に変換するのに苦労しています...
ご覧のとおり、これにより、プライマリ mongo サーバーで膨大な (ほぼ 100%) の CPU 待機時間が発生しますが、2 つのセカンダリ サーバーには影響はありません...
Mongo のドキュメントでページ フォールトについて次のように説明されています。
ページ フォールトは、MongoDB が物理メモリにないデータを必要とし、仮想メモリから読み取る必要がある回数を表します。ページ フォールトを確認するには、serverStatus コマンドの extra_info.page_faults 値を参照してください。このデータは、Linux システムでのみ使用できます。
単独では、ページ フォールトは軽微であり、すぐに完了します。ただし、全体として、多数のページ フォールトは通常、MongoDB がディスクから読み込んでいるデータが多すぎることを示しており、いくつかの根本的な原因と推奨事項を示している可能性があります。多くの場合、MongoDB の読み取りロックは、ページ フォールトの後に「解放」して、他のプロセスが読み取りを行えるようにし、次のページがメモリに読み込まれるのを待つ間のブロックを回避します。このアプローチにより同時実行性が向上し、大量のシステムでは全体的なスループットも向上します。
可能であれば、MongoDB がアクセスできる RAM の量を増やすと、ページ フォールトの数を減らすのに役立つ場合があります。これが不可能な場合は、シャード クラスターをデプロイするか、デプロイに 1 つ以上のシャードを追加して、mongod インスタンス間で負荷を分散することを検討してください。
そこで、推奨されるコマンドを試してみましたが、これは非常に役に立ちません。
PRIMARY> db.serverStatus().extra_info
{
"note" : "fields vary by platform",
"heap_usage_bytes" : 36265008,
"page_faults" : 4536924
}
もちろん、サーバーのサイズを大きくする (RAM を増やす) こともできますが、それには費用がかかり、やり過ぎのように思えます。シャーディングを実装する必要がありますが、どのコレクションにシャーディングが必要なのか実際にはわかりません! したがって、障害が発生している場所 (特定のコマンドが障害を引き起こしている) を特定する方法が必要です。
助けてくれてありがとう。