パフォーマンス

IBM Cloud® Databases for MongoDB のデプロイメントは、使用状況に合わせて手動でスケーリングすることも、特定のリソース条件下で自動スケーリングするように構成することもできます。 配備のパフォーマンスをチューニングする場合、まずいくつかの要因を考慮してください。

デプロイメントのモニタリング

Databases for MongoDB デプロイメントは、デプロイメント上のリソース使用状況の基本モニタリングのための IBM Cloud® Monitoring サービスと統合されています。 使用可能なメトリック (ディスク使用量、IOPS など) の多くは、デプロイメントに自動スケーリングを構成する役に立ちます。 使用状況の傾向を観察し、それに対応するように自動スケーリングを構成することにより、リソースの枯渇のためにデータベースが不安定になる前に、パフォーマンス上の問題を軽減することができます。

ディスク使用

MongoDB がデータの保存に使用している容量が気になる場合は、ネイティブの MongoDB データストレージ診断を実行して、データベース、コレクション、インデックスなどのサイズを調べることができます。 データ・セットのおおよそのサイズが既知で固定である場合は、データに合わせてディスクを手動でスケーリングできます。 データ・セットが時間の経過とともに予測可能な速度で増加する場合は、ディスク使用量が特定のしきい値に達したときにディスク・サイズを増やすように自動スケーリングを構成できます。

ディスク入出力

Databases for MongoDB のデプロイメントの IOPS (1 秒あたりの入出力操作数) の数値は、ストレージ・ボリュームのタイプによって制限されます。 Databases for MongoDB 導入用のストレージ・ボリュームは、 Block Storage Endurance Volumes で、GB あたり 10 IOPS の階層です。 入出力使用制限に達すると、データベースの応答が遅くなったり、無応答のように見えたりすることがあります。 最適化されていないクエリ、 インデックスの構築、新しいインデックスの作成などは、IOPSの急上昇を引き起こす可能性がありますが、アプリケーションの通常の作業負荷が、デプロイメントで利用可能なIOPSを超える可能性もあります。

ディスク・スペースを大きくすることによって、デプロイメントで使用できる IOPS 数を増やすことができます。 デプロイメントの入出力使用率が特定の飽和点に達した状態が長期間続いた場合に、ディスク・サイズを自動的に大きくするように、自動スケーリングを構成することもできます。

詳しくは、 MongoDB の資料を参照してください。

WiredTiger のキャッシュおよびメモリー

Databases for MongoDB は、 WiredTiger ストレージ・エンジンを使用しており、ファイル・システム・メモリー・キャッシュと内部メモリー・キャッシュの両方を使用している。 MongoDB のパフォーマンスは、内部キャッシュからデータを提供する場合に最も高くなり、データがファイル・システム・キャッシュ内にある場合は少し低くなり、ディスクからデータを取得しなければならない場合は最も低くなります。

内部キャッシュのデフォルトサイズは、 50% of (total RAM per member - 1 GB) または 256 MB のいずれか大きい方である。 たとえば、 Databases for MongoDB デプロイの最小メモリサイズは、データメンバあたり4096MBなので、内部キャッシュは1536MBです( 0.5 * (4096 MB - 1024 MB) = 1536 MB.

内部/ファイル・システムのキャッシュの割合をユーザーがデプロイメントに構成することはできませんが、データベースのパフォーマンスが高くなるように、メモリーの総量をスケーリングして内部キャッシュを調整することはできます。 たとえば、メンバー1人あたりのメモリを5120MBに拡張した場合、内部キャッシュ・サイズは2048MBになる。 0.5 * (5120 MB - 1024 MB) = 2048 MB.

自動スケーリングを使用するもう 1 つの方法は、ディスク入出力の使用率が特定のしきい値に達したときにスケーリングするようにメモリーを設定することです。 メモリーを増やすと、MongoDB がディスクに対して読み書きを行う量が減るので、メモリーを追加してより多くのキャッシュをサポートすることで、ディスク入出力の負荷を軽減できる可能性があります。

WiredTiger、キャッシュについての詳細は MongoDB

照会のパフォーマンス

MongoDB ドキュメントには、 クエリ・パフォーマンスの分析に関するハウツーなど、クエリ・パフォーマンスに関する複数のリソースがあります。 クエリのパフォーマンスについて大まかな把握ができたら、 クエリを最適化するヒントもある。

より高度なトピックとして、 MongoDB がどのように クエリプランを管理するかを学ぶことができます。

MongoDB のその他のモニタリング・ツール

MongoDB のネイティブのモニタリング機能の一部を利用することもできます。 例えば、 mongotopmongostatの両方を使用できます。

mongotop 30 --username admin --password $PASSWORD --tls --tlsCAFile $CERTFILE --authenticationDatabase admin --host host1.databases.appdomain.cloud:31712, host2.databases.appdomain.cloud:31712

mongostat -n 20 1 --username admin --password $PASSWORD --tls --tlsCAFile $CERTFILE --authenticationDatabase admin --host host1.databases.appdomain.cloud:31712,host2.databases.appdomain.cloud:31712 --json

MongoDB データベースの状況を報告する 文書化されたコマンド のいずれかを実行します。

MongoDB、多くのユーティリティやコマンドを実行するには Cluster Monitor ロールが必要です。 この役割は、admin のデフォルトの役割セットには含まれていません。 デプロイメントの admin ユーザーに クラスター・モニター役割を付与 します。

詳しくは、 Best Practices ブログ投稿 を参照してください。