このセクションでは、ハードウェアコンポーネントとその mongot プロセスへの影響の包括的な概要について説明します。サイズ設定 ガイドライン、重要なモニタリングの推奨事項、実用的なスケーリングに関するアドバイスが提供されます。
CPU
影響
CPU の数と品質を増やすと、一般にレプリケーションスループットとクエリスループット（QPS）に正の影響が生じます。CPU は、同時セグメント検索を使用するクエリに特に活用されます。
サイズ設定 ガイドライン
クエリスループットに基づく有用な推定値は、CPU コアあたり 10 QPS です。これはベースラインであり、実際の QPS はクエリの複雑さとインデックスマッピングによって影響を受けるためです。
モニタリング
CPU 使用率が一貫して 80% を超える場合は、増やすアップ（CPU コアの追加）の必要があることを示しますが、20% を一貫して下回る場合は、増やすダウン（CPU コアの削減）の機会がある可能性があります。
スケーリング
水平スケーリング （mongot ノードを追加）により、合計 CPU が増加して QPS が増加します。
注意
水平スケーリングでは 、各 mongot がソースコレクションからインデックスデータを複製する必要があるため、レプリカセットに追加の負荷がかかります。各検索またはベクトル検索インデックスでは、mongot ごとに新しい変更ストリームが作成されます。これにより、レプリカセットが追加のレプリケーション負荷を処理するサイズに設定されていない場合は、パフォーマンスが低下する可能性があります。
垂直スケーリングは、より多くのクエリを並列に処理できるようにし、クエリリクエストのキューを減らすことで、主にクエリのレイテンシに影響します。
メモリ（RAM）
影響
mongot は、 JVMヒープ（ Lucene 関連のデータ構造とキャッシュ）とファイルシステムキャッシュ（インデックス データに効率的にアクセスするため）にシステム メモリを使用します。
サイズ設定 ガイドライン
コロケーションされたアーキテクチャの場合、デフォルト設定は適切なバランスを提供します。ただし、専用インフラストラクチャの場合、デフォルトのJVMヒープ サイズを調整すると役立ちます。次のセクションでは、特定のハードウェアとワークロードにこの設定を最適化するためのガイダンスが提供されます。
JVMヒープのサイズ設定
mongot は、主に Lucene 関連のデータ構造とキャッシュにJVMヒープを使用します。一般に、mongot のヒープ使用量は、インデックス化されたフィールド数に応じてほぼスケーリングされます。ヒープ使用量は、ドキュメント数やベクトル数によって大きく影響されません。全文検索およびベクトル検索の効果的なデータ モデリングでは、通常、インデックス フィールドの数が最小限に抑えられます。
推定値として、使用可能なシステムメモリの合計の 50% を、最大値約 30 GBを超えないように割り当てます。これにより、 OS ファイルシステムキャッシュに十分なメモリを使用できます。これは、ディスクから頻繁にアクセスするインデックスセグメントをキャッシュすることで Lucene のパフォーマンスに重要な役割を果たします。デフォルトでは、mongot はJVMヒープ用に使用可能な合計システムメモリの最大 25% まで、最大 32 GB （システムメモリ 128 GBを使用）を割り当てます。これらのサイズ設定ガイドラインは、このデフォルトの よりも増加しています。
さらに、ヒープ サイズを約 30 GB未満に維持すると、 JVM は圧縮オブジェクトポインターを使用してメモリを節約できます。ヒープ サイズがこの 30 GB の制限を超えて増加する場合は、ヒープ サイズを直接 48 GB以上に増やすことをお勧めします。
デフォルトのヒープサイズ設定を上書きするには、必要なサイズを mongot 起動スクリプトの引数として指定します。最小ヒープサイズ（Xms）と最大ヒープサイズ（Xmx）を同じ値に設定することをお勧めします。（例: ）。
/etc/mongot/mongot --config /etc/mongot/mongot.conf --jvm-flags "-Xms4g -Xmx4g"
ファイルシステム キャッシュ
インデックス セグメントはメモリマップされたファイルを介してアクセスされるため、クエリのレイテンシとスループットはOS の ファイルシステムキャッシュに大きく依存します。ファイルシステムキャッシュのワークロードに十分なメモリを確保する必要があります。mongot に分離されたハードウェアを使用すると、キャッシュの競合を軽減できます。
注意
使用可能なメモリの 50% を超えてJVMヒープ サイズを増やすと、ファイルシステムキャッシュを使用するためのメモリが不足する可能性があります。
ベクトル検索ガイダンス
ベクトル検索の場合、「検索プロセス メモリ」は、 HNSWグラフのようなデータ構造を効率的にストレージために使用されます。ベクトル インデックス サイズが 3 GBを超える場合は、ベクトル量子化を使用します。ベクトルを量子化する場合、インデックス全体ではなく、インデックスの 4% のみがメモリに保存される必要があります。
メモリ不足のモニタリング
検索ページフォールトとディスク IOPSの増加は、オペレーティング システムがディスクから必要なページを頻繁に取得し、メモリが不足していることを示します。1000/s 以上のページフォールトが一貫して表示されている場合は、スケールアップを検討する必要がある指標です。
スケーリング
mongot プロセスが OutOfMemoryError で終了する場合、 JVMヒープはインデックス作成とクエリ ワークワークロードに対して小さすぎることを意味します。これは、多くの場合、ソース フィールドを保存しすぎた場合、または非構造化データの 動的マッピング による「マッピングの急増」が発生します。この問題を解決するための主な推奨事項は次のとおりです。
Javaヒープ サイズの増加（垂直スケーリング）
最も直接的な解決策は、より多くのRAM をmongo プロセスに割り当てることです。 ホストに使用可能なメモリがある場合は、最大Javaヒープ サイズを増やすことができます。これにより、インデックスの定義を変更せずに、既存のインデックスとクエリ パターンのヘッドルームが向上します。
インデックス メモリのフットプリントを削減
ハードウェアのスケーリングがオプションでない場合、または効率のために最適化 する場合は、インデックスに必要なメモリの量を減らすことができます。
インデックスの定義を確認し、 storedSource フィールドを減らし、必須フィールドをすべてインデックスから排除して、ヒープ負荷を軽減します。
静的マッピング を使用します。動的マッピングでは、コレクション内のドキュメント内のすべての一意のフィールドにインデックスフィールドが作成されます。より選択的で重要なフィールドのみにインデックスを作成すると、ヒープ消費が削減されます。
ディスクのスループットとストレージ
影響
読み取り IOPS と書込み IOPS の両方が mongot のパフォーマンスにとって重要で、レプリケーション、最初の同期、 クエリスループット に影響します。ほとんどのユースケースでは、汎用 SSD をお勧めします。
一般的に、読み取り IOPS と書込み IOPS の両方が mongo のパフォーマンスにとって重要です。 データをレプリケートすると、ディスクへの書き込みだけでなく、読み取りも行われ、古いインデックスセグメントはより大きなセグメントにマージされます。したがって、ディスクスループットは、クエリスループットから最初の同期インデックススループットまで、mongo のパフォーマンスのすべての面にさまざまな影響を与えます。
サイズ設定 ガイドライン
ディスク サイズ ガイドラインを参照してください。
インデックスの再ビルド
Atlas Searchインデックスの作成または再構築は、リソースを集中的に消費するため、クラスターのパフォーマンスに影響可能性があります。ダウンタイムなしでインデックスを作成するには、古いインデックスで使用されているディスク領域の 125% に等しい空きディスク領域を割り当てます。再構築中は古いインデックスがディスク上に保持されるため、このヘッドルームは重要です。一般的な推奨として、インデックスの再構築に対応するために、mongot のディスク容量を 2 倍にする必要があります。
モニタリング
現在のインデックス消費を追跡するには、Search Disk Space Used をモニターします。1K を超える継続的な IOPS 使用量は調査を警告します。
注意
mongot ホストのストレージ使用率が 90% に達すると、mongot は読み取り専用状態になります。この状態でも、mongot は現在の状態のインデックスを使用してクエリを処理し続けます。ソースコレクションに軽減なしの変更が加えられた場合、検索結果が古くなる可能性があります。
ソース コレクションとのインデックス同期を再開するには、インデックスデータを削除するか、ストレージキャパシティーを増やす ことで、ストレージ使用率を 85% 未満に減らします。
スケーリング
インデックスサイズを増やし、インデックスデータのボリュームが大きくなる場合（特に バイナリ数量化を使用する場合）、インデックスデータの大きなワーキングセットをサポートするのに十分なメモリがあるインスタンスを確認してください。ただし、必要なメモリの正確な量は、ワークロードによって異なります。
例、全体でクエリがほとんど実行されない大きなデータセットでは、全体で頻繁にクエリを実行する同じサイズのデータセットよりもメモリが少なく、低レイテンシでクエリを処理できる場合があります。
ストレージとメモリの比率が高い mongot を使用する場合は、メモリ使用量を慎重に監視してください。例、64 GBのメモリは 6400 GBのストレージに十分ではない可能性があります。