この記事はもともとMongodbで公開されました。 SitePointを可能なものとしてサポートしてくれたパートナーに感謝します。
さまざまな内部キャッシュとディスクのパフォーマンスとの関係を理解し、これらの関係がデータベースとアプリケーションのパフォーマンスにどのように影響するかは困難です。 YCSBベンチマークを使用して、作業セット（テストで使用されるドキュメントの数）とディスクのパフォーマンスを変更して、その関係をよりよく実証しました。結果を確認する際に、一般的なデータベースの使用パターンの理解を改善するために、いくつかのMongoDB内部メカニズムを導入します。
キーポイント
abstract
システム全体のパフォーマンスの主な影響は、作業セットがストレージエンジンキャッシュサイズ（データの保存に特化したメモリ）とディスクパフォーマンス（データへのアクセスの速さに関する物理的な制限を提供する方法）にどのように関連しているかです。YCSBを使用して、ディスクのパフォーマンスとキャッシュサイズの相互作用を調査し、これらの2つの要因がパフォーマンスにどのように影響するかを示しました。このテストではYCSBを使用していますが、合成ベンチマークは生産ワークロードを表すことはできません。これらの方法で得られたレイテンシとスループット数は、生産パフォーマンスにマッピングされません。これらのテストには、MongoDB 3.4.10、YCSB 0.14、およびMongoDB 3.6.0ドライバーを使用しました。 YCSBは、16個のスレッドと「均一な」読み取り専用ワークロードで構成されています。
作業セットをメモリに入力すると、最適なアプリケーションパフォーマンスが提供され、この制限を超えると、レイテンシと全体的なスループットがマイナスに影響することを実証します。
ディスクメトリックの理解ディスクのパフォーマンスを検討する場合、4つの重要な指標があります。
ディスクのパフォーマンスをテスト
クラウドプロバイダーは、特定のボリュームとディスクにIOPSのしきい値を提供する場合があり、ディスクメーカーは予想されるパフォーマンス数値を公開する場合がありますが、システムの実際の結果は異なる場合があります。 IOテストの実行は、ディスクのパフォーマンスに問題がある場合に非常に役立ちます。
通常、テストにはFIO（柔軟なIOテスター）を使用します。 10GBのデータでテストしました。IoEngineはPSYNCで、読み取り範囲は4kb〜32kbです。デフォルトのFIO設定はWiredTigerワークロードを表していませんが、この構成はWiredTigerディスク使用の適切な近似であることがわかりました。
すべてのテストは、3つのディスクシナリオで繰り返されます
シーン1
AWS C5 IO1 100GBボリュームによって提供されるデフォルトのディスク設定。 5000 IOPS
シーン2
ディスクを600 IOPSに制限し、7ミリ秒の遅延を導入します。これは、ハードドライブを備えた典型的なRAID10 SANのパフォーマンスを反映する必要があります
シーン3
さらに、7ミリ秒の遅延でディスクを150 IOPSに制限します。これにより、通常の回転ハードドライブをシミュレートする必要があります。
クエリディスクから提供する方法は？
WiredTigerストレージエンジン独自のキャッシュを実行します。デフォルトでは、WiredTigerキャッシュサイズはシステムメモリを引いた50％マイナス1GBです。他のシステムプロセス、ファイルシステムキャッシュ、および追加のメモリを使用する内部MONGODB操作（構築インデックス、メモリの並べ替え、重複排除の結果、テキストスコア、処理と集約に参加）十分なスペースを離れます。キャッシュの膨満感によるパフォーマンスの低下を防ぐために、使用率が80％を超えると、WiredTigerは自動的にキャッシュからデータの排出データを開始します。私たちのテストでは、これは有効なキャッシュサイズが（7634MB - 1024MB）*。5*.8、または2644MBであることを意味します。
すべてのクエリはWiredTigerによってキャッシュされます。これは、クエリがインデックスとドキュメントをファイルシステムキャッシュを介してWiredTigerキャッシュに読み込まれ、結果を返すことを意味します。要求されたデータがすでにキャッシュにある場合は、この手順をスキップします。
WiredTigerは、スナッピー圧縮アルゴリズムを使用して、デフォルトでドキュメントを保存します。ファイルシステムキャッシュから読み取られたデータは、WiredTigerキャッシュに保存される前に減圧されます。インデックスは、デフォルトでプレフィックスを使用して圧縮され、ディスクとWiredTigerキャッシュの両方で圧縮されます。
ファイルシステムキャッシュは、アクセスを容易にするためにメモリに頻繁にアクセスされるファイルを保存するために使用されるオペレーティングシステム構造です。 Linuxはキャッシュされたファイルで非常にアクティブであり、ファイルシステムキャッシュを使用して利用可能なすべてのメモリを消費しようとします。より多くのメモリが必要な場合、ファイルシステムキャッシュが排出され、アプリケーションのメモリが増えます。
これは、100 YCSB読み取り操作によって生成されたYCSBコレクションへのディスクアクセスを示すアニメーショングラフです。各操作は、単一のドキュメントの_IDの単一の検索です。
左上隅は、WiredTigerコレクションファイルの最初のバイトを表します。ディスクの位置は、右側とサラウンドに増分されます。各行は、WiredTigerコレクションファイルの3.5MBセグメントを表します。アクセスは年代順に配置され、アニメーションフレームで表されます。アクセスは、現在のディスクアクセスを強調するために赤と緑の正方形で表されます。
3.5 MB対4kb
ここでは、収集データファイルがメモリに読み取られていることがわかります。データはBツリーに保存されているため、ドキュメントを見つけて読む前に、ディスク上の1つ以上の場所にアクセスして、ドキュメントのディスクの場所（小さなアクセス）を見つける必要がある場合があります（より大きなアクセス）。
これは、MongoDBクエリの典型的なアクセスパターンを示しています。ドキュメントは、ディスク上で互いに近づいていないことを示しています。これはまた、お互いを挿入した後でも、ドキュメントが連続ディスクの場所にある可能性は低いことを示しています。
WiredTigerストレージエンジンは、「完全に読み取る」ように設計されています。必要なすべてのデータの読み取りリクエストを一度に発行します。これにより、WiredTigerの展開のディスクアドバンスリードをゼロに制限することを推奨することができます。その後のアクセスは、事前読み取りによって取得された追加データを利用する可能性は低いためです。
ワーキングセットは、キャッシュに適しています
最初のテストセットでは、レコードカウントを200万に設定し、データとインデックスの合計サイズは2.43 GB、つまりキャッシュの92％になります。
ここでは、シーン1の強力なパフォーマンスは1秒あたり76,113のリクエストです。ファイルシステムのキャッシュ統計を確認すると、WiredTigerキャッシュのヒット率は100％、アクセスがなく、ファイルシステムキャッシュにバイトが読み取られていないことがわかりました。つまり、テスト中に追加のIOは必要ありません。
予想通り、シナリオ2およびシナリオ3では、ディスクのパフォーマンスの変化（7ミリ秒のレイテンシを追加し、IOPを600または150に制限する）は、スループット（それぞれ69、579.5および70,252の操作/秒）に最小限の影響を与えます。
作業セットはWiredTigerキャッシュよりも大きいですが、ファイルシステムのキャッシュに適しています。 最新のオペレーティングシステムキャッシュは、読み取りパフォーマンスを改善するためにファイルに頻繁にアクセスしました。ファイルはすでにメモリになっているため、キャッシュされたファイルにアクセスしても、物理的な読み取り値は発生しません。 Free Linuxコマンドによって表示されるファイルシステムキャッシュ統計には、ファイルシステムキャッシュのサイズが詳しく説明されています。
記録数を200万から300万に増やすと、データとインデックスの合計サイズを3.66GBに増やし、Wiredtigerキャッシュサービスだけのものよりも38％大きくなりました。メトリックは、WiredTigerキャッシュに平均548 Mbpsを読み取ることを明確に示していますが、ファイルシステムキャッシュメトリックをチェックすると、99.9％のヒット率が観察できます。
このテストでは、パフォーマンスが低下し始め、1秒あたり66,720の操作のみが実行され、ベースラインと比較して8％減少しましたが、ベースラインはWiredtigerキャッシュサービスからのみでした。この場合、予想どおり
ディスクのパフォーマンスの低下は、全体的なスループット（それぞれ64,484および64,229の操作）に大きな影響を与えません。ファイルシステムキャッシュから読み取りのペナルティは、ドキュメントが圧縮しやすい場合、またはCPUが制限要因である場合、より明白になります。
P99レイテンシが.53 – .55 msに54％増加していることに気付きました。
ワーキングセットは、WiredTigerおよびファイルシステムキャッシュよりもわずかに大きいWiredTigerとFile System Cacheが協力して、クエリを提供するデータを提供すると判断しました。ただし、記録数を300万から400万に増やすと、これらのキャッシュを活用してクエリを提供することはできなくなりました。データサイズは4.8GBに増加し、WiredTigerキャッシュよりも82％大きくなりました。
ここでは、257.4 MbpsでWiredTigerキャッシュを読み取ります。ファイルシステムキャッシュのヒット率は93〜96％に減少します。これは、読み取りの4〜7％がディスクからの物理的な読み取りにつながることを意味します。
利用可能なIOPSとディスクレイテンシの変更は、このテストのパフォーマンスに大きな影響を与えます。
99パーセンタイルの応答遅延がさらに増加します。シーン1:19ミリ秒、シーン2：171ミリ秒、シーン3：770ミリ秒。これは、キャッシュの状況と比較して43回、389回、1751回です。完全にキャッシュに優しい以前のテストと比較して、MongoDBが完全な5000 IOPSを提供すると、パフォーマンスが75％減少したことがわかりました。シナリオ2およびシナリオ3は、それぞれ1秒あたり5139.5および737.95の操作を達成し、IOボトルネックをさらに証明しました。
作業セットは、WiredTigerおよびファイルシステムキャッシュよりもはるかに大きい500万のレコードに移動すると、データとインデックスサイズを6.09GBに増やします。これは、WiredTigerとファイルシステムの合計キャッシュよりも大きくなります。 IOPSの下にスループットが表示されます。この場合、ファイルシステムのキャッシュからWiredTigerの読み取りの81％をまだ提供していますが、ディスクオーバーフローからの読み取りはIOを飽和させています。このテストのファイルシステムキャッシュの読み取り速度は71、8.3、および1.9 Mbpsです。
99パーセンタイルの応答遅延がさらに増加します。シナリオ1：22ms、シナリオ2：199ms、シナリオ3：810msは、キャッシュ内応答の遅延と比較して、52回、454回、1841回です。ここでは、ディスクIOPSを変更するとスループットが大きく影響します。
abstract
この一連のテストを通じて、2つの主要なポイントを証明しました。
作業セットがキャッシュに適している場合、ディスクのパフォーマンスはアプリケーションのパフォーマンスに大きく影響しません。作業セットが使用可能なメモリを超えると、
ディスクの性能は、スループットの制限要因になります。MongoDBは、メモリとディスクのスペースを使用してデータを保存および管理します。データストレージにメモリマッピングされたファイルシステムを使用します。つまり、データファイル全体をRAMにマッピングします。これにより、MongoDBは大規模なデータセットを効率的に処理できます。オペレーティングシステムの仮想メモリサブシステム管理の詳細は、必要に応じてメモリにデータを交換します。一方、ディスクスペースは、データファイル、インデックス、ログを保存するために使用されます。 MongoDBは、書き込み操作を最適化するために、大きなチャンクでディスクスペースを自動的に割り当てます。 Mongodbでの高ディスクI/O使用率の影響は何ですか？
MongoDBは、ディスクスペースの使用量を監視するためのいくつかのツールを提供します。 db.stats（）コマンドは、データファイルとインデックスの合計サイズを含むデータベースの高レベルの概要を提供します。 db.collection.stats（）コマンドは、データとインデックスのサイズを含む特定のコレクションに関するより詳細な情報を提供します。さらに、Mongodb Atlas（MongoDBが提供するサービスとしてのデータベース製品）は、高ディスクスペースの使用に関するアラートを含む包括的な監視ツールのセットを提供します。
MongoDBで高ディスクスペースの使用率に対処するためのいくつかの戦略があります。 1つの方法は、不要なデータまたはコレクションを削除することです。別のアプローチは、データファイルをデフラグして未使用のディスクスペースをリサイクルするコンパクトコマンドを使用することです。ただし、このコマンドには多くの無料ディスクスペースが必要であり、データベースのパフォーマンスに影響を与える可能性があります。シャード（データを複数のサーバーに配布）も、ディスクスペースの使用を管理するのに役立ちます。
RAMドライブは、オペレーティングシステムがディスクドライブと見なすメモリです。 RAMはディスクストレージよりもはるかに高速であるため、RAMドライブを使用すると、高速データアクセスが必要なアプリケーションのパフォーマンスが大幅に向上する可能性があります。ただし、RAMは揮発性であるため、システムが再起動するとRAMドライブに保存されているデータが失われます。 MongoDBのコンテキストでは、RAMドライブを使用して、パフォーマンスを改善するために頻繁にアクセスされるデータまたはインデックスを保存できます。ただし、システムが再起動した場合にデータ損失が発生する可能性があるため、これは注意して行う必要があります。
MongoDBは、メモリ管理のために基礎となるオペレーティングシステムに依存しています。メモリマッピングされたファイルシステムを使用して、オペレーティングシステムの仮想メモリサブシステムがメモリ内のデータの詳細とディスク上のデータを管理できるようにします。このアプローチにより、MongoDBは大規模なデータセットを効率的に処理することができますが、MongoDBのメモリ使用量が同じシステムで実行されている他のプロセスによって影響を受ける可能性があることも意味します。
mongodbのメモリ使用量を最適化するためのいくつかの戦略があります。 1つの方法は、作業セットがメモリに適していることを確認することです。作業セットは、データの部分に頻繁にアクセスされます。作業セットがメモリに適している場合、MongoDBは費用のかかるディスクI/O操作を回避できます。別のアプローチは、インデックスを効率的に使用することです。インデックスはクエリパフォーマンスを大幅に改善できますが、メモリを消費することもできます。したがって、インデックスを賢く作成し、メモリの使用に対する影響を監視することが重要です。
MongoDBはWrite-Pre-Logを使用してデータの整合性を確保します。データファイルに変更が加えられる前に、最初にログに書き込まれます。これにより、MongoDBはクラッシュまたは停電から回復することができます。ただし、ロギングはディスクI/O操作を増加させる可能性があり、パフォーマンスに影響を与える可能性があります。したがって、ディスクI/Oの使用率を監視し、必要に応じて最適化するための措置を講じることが重要です。
MongoDBのディスクI/O操作を最適化するためのいくつかの戦略があります。 1つの方法は、従来のハードドライブよりも多くのIOPを処理できるSSDを使用することです。別のアプローチは、書き込み操作に最適化されたRAID構成を使用することです。さらに、MongoDBのロギング設定を調整して、ディスクI/Oへの影響を減らすことができます。ただし、データの整合性に影響を与える可能性があるため、これは注意して行う必要があります。
メモリとディスクのパフォーマンスは、MongoDBデータベースの全体的なパフォーマンスの重要な要素です。作業セットがメモリに適している場合、MongoDBはコストのかかるディスクI/O操作を回避できます。これにより、パフォーマンスが大幅に向上する可能性があります。同様に、効果的なディスクI/O操作は、書き込み操作のパフォーマンスを改善し、データの整合性を確保することができます。したがって、MongoDBデータベースの最高のパフォーマンスを確保するために、メモリとディスクのパフォーマンスを監視および最適化することが重要です。
以上がメモリとディスクのパフォーマンスがMongoDBデータベースにどのように影響するかの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
