パフォーマンスに関する注意事項

このページでは、最適なパフォーマンスを得るために Parallelstore 環境を構成する方法について説明します。

一般的な推奨事項

  • デフォルトのパフォーマンスを改善するため、ls からすべてのエイリアスを削除しました。多くのシステムでは、ls -color=auto にエイリアスされています。これは、デフォルトの Parallelstore 構成でははるかに遅くなります。

  • リスト オペレーションのパフォーマンスが低い場合は、dfuse マウントのキャッシュを有効にすることを検討してください。

インターセプト ライブラリ

libioil ライブラリを使用すると、libc を使用するアプリケーションから DFuse への読み取りオペレーションと書き込みオペレーションのパフォーマンスを向上させることができます。このライブラリは、アプリケーションからの POSIX の読み取り呼び出しと書き込み呼び出しをインターセプトしてカーネルをバイパスし、ユーザー空間で直接処理します。詳細については、インターセプト ライブラリをご覧ください。

ほとんどの場合、プロセスごとまたはアプリケーションごとの呼び出しでインターセプト ライブラリを使用することをおすすめします。

インターセプト ライブラリを使用しない場合や使用する必要がない状況は次のとおりです。

  • インターセプト ライブラリを使用できるのは、libc でビルドされたアプリケーションのみです。
  • 同じファイルに繰り返しアクセスするなど、キャッシュのメリットがあるワークロードの場合は、インターセプト ライブラリを使用しないことをおすすめします。
  • ワークロードがメタデータ集約型の場合（多数の小さなファイルや非常に大きなディレクトリ リストを扱う場合など）、インターセプト ライブラリによってパフォーマンスが向上する可能性は低くなります。

LD_PRELOAD 呼び出しは、シェル環境で環境変数として設定できますが、設定すると問題が発生することがあります。代わりに、各コマンドで指定することをおすすめします。

または、-lioil フラグを使用して、コンパイル時にインターセプト ライブラリをアプリにリンクすることもできます。

dfuse キャッシュ保存

dfuse では、デフォルトでキャッシングが有効になっています。

Parallelstore インスタンスをマウントするときに dfuse で使用されるキャッシュ関連のフラグは 2 つあります。

  • --disable-wb-cache は、書き戻しキャッシュではなく書き込みスルーを使用します。
  • --disable-caching はすべてのキャッシュを無効にします。

キャッシュとパフォーマンスには、次の推奨事項が適用されます。

  • インターセプト ライブラリを使用している場合、書き戻しキャッシュはバイパスされます。インターセプト ライブラリを使用する場合は、--disable-wb-cache を指定することをおすすめします。
  • ワークロードで多くのファイルを一度に読み取る場合は、キャッシュ保存を無効にする必要があります。
  • 多くのクライアントがファイルを変更し、他のクライアントが更新をすぐに利用できるようにする必要があるワークロードでは、キャッシュを無効にする必要があります。
  • ワークロードが同じファイルを繰り返し読み取る場合は、キャッシュ保存によってパフォーマンスを改善できます。これは、ファイルがクライアントのメモリに収まる場合に特に当てはまります。dfuse は、キャッシュに Linux ページキャッシュを使用します。

  • 大規模なファイルへの小さな I/O で構成されるワークロードの場合、キャッシュを有効にするだけでなく、拡散読み取りを増やすと効果的です。dfuse の読み取り先読みを増やすには、dfuse がマウントされた後、次のコマンドを実行します。

    echo 4096 > /sys/class/bdi/\$(mountpoint -d /mnt)/read_ahead_kb
echo 100 > /sys/class/bdi/\$(mountpoint -d /mnt)/max_ratio

ワークロードに上記のシナリオが混在している場合は、同じ Parallelstore インスタンスを、異なるキャッシュ設定で複数のマウントポイントにマウントできます。

スレッド数とイベントキュー数

Parallelstore インスタンスをマウントする場合は、--thread-count と --eq-count に次の値を設定することをおすすめします。

  • スレッド数の値は vCPU コア数を超えないようにしてください。
  • 推奨される最大スレッド数は 16 ～ 20 です。この数を超えると、使用可能なコア数に関係なく、パフォーマンス上のメリットはほとんどありません。
  • イベント キューの値は、スレッド数値の半分にする必要があります。

ワークロードに非常に多くの小規模なファイル オペレーションとメタデータへの大量のアクセスが含まれている場合は、これらの推奨値を超えて数を増やすことをテストできます。

ファイル ストライプ設定

ファイル ストライプは、ファイルをブロック（ストライプ）に分割し、複数のストレージ ターゲットに分散するデータ ストレージ手法です。ファイル ストリッピングを使用すると、インスタンスをバッキングする複数のストレージ ターゲットへの並列読み取りと書き込みが可能になり、パフォーマンスを向上させることができます。

Parallelstore インスタンスを作成するときに、次の 3 つのファイル ストライプ設定のいずれかを指定できます。

  • 最小
  • バランス
  • 最大

これらの設定は、Parallelstore のパフォーマンスに大きな影響を与える可能性があります。ほとんどのワークロードでは、バランス設定をおすすめします。これは、ほとんどのワークロードにとって妥当な妥協点です。バランス設定でのパフォーマンスが許容できない場合:

  • 最小設定は、特に平均ファイルサイズが 256 KB 未満の場合、小規模なファイルが多数あるワークロードのパフォーマンスを向上させる可能性があります。

  • 最大設定を使用すると、特に多くのクライアントが同じファイルへのアクセスを共有している場合、非常に大きなファイル（通常 8 GB を超えるファイル）を使用するワークロードのパフォーマンスが向上する可能性があります。

高度なチューニングを行うには、daos ツールでファイルごとまたはディレクトリごとの設定を行います。高度なチューニングを試すと、パフォーマンス関連のリスクが生じるため、通常はおすすめしません。詳細については、DAOS でのデータの冗長性とシャーディングについてをご覧ください。

ディレクトリ ストライプ設定

Parallelstore インスタンスを作成するときに、次の 3 つのディレクトリ ストライプ設定のいずれかを指定できます。

  • 最小
  • バランス
  • 最大

ほとんどのワークロードでは、最大設定をおすすめします。

大規模なディレクトリの大量のリストに関連するワークロードでは、バランスまたは最小の設定により、リストのパフォーマンスが向上する場合があります。ただし、他のオペレーション（特にファイルの作成）のパフォーマンスが低下する可能性があります。

マルチユーザー

dfuse ツールを使用して Parallelstore インスタンスをマウントする場合は、--multi-user フラグを指定することをおすすめします。このフラグは、DFuse プロセスを実行しているユーザーだけでなく、クライアント上のすべてのユーザーがファイル システムを使用できるようにカーネルに指示します。DFuse は一般的なマルチユーザー ファイル システムのように見え、標準の chown 呼び出しと chgrp 呼び出しが有効になります。すべてのファイル システム エントリは、POSIX ファイル システムで通常どおり、作成したユーザーが所有します。

--multi-user フラグを指定する場合は、次の行を追加して /etc/fuse.conf を root として更新する必要があります。

user_allow_other

インスタンスをマルチユーザーとしてマウントしても、パフォーマンスに影響はないようです。

消失訂正符号の設定

消失訂正符号は 2+1 に設定されています。この設定は変更できません。EC2+1 を使用しない I/O は拒否されます。

Google Kubernetes Engine サイドカー コンテナのリソース割り当て

ほとんどの場合、Google Kubernetes Engine と Parallelstore のパフォーマンスが不十分なのは、Parallelstore サイドカー コンテナに割り当てられた CPU またはメモリが不十分なためです。リソースを適切に割り当てるには、次のヒントを考慮してください。

  • サイドカー コンテナのリソースを構成するで説明されている考慮事項を確認します。リソース割り当てを増やす必要がある理由と、Pod アノテーションを使用してサイドカー コンテナのリソース割り当てを構成する方法について学習します。

  • 値 0 を使用すると、Standard クラスタのリソース上限またはリクエストをオフにできます。たとえば、gke-parallelstore/cpu-limit: 0 と gke-parallelstore/memory-limit: 0 を設定すると、サイドカー コンテナの CPU とメモリの上限は空になり、デフォルトのリクエストが使用されます。この設定は、ワークロードに必要な dfuse のリソースの量が不明で、ノード上の使用可能なすべてのリソースを使用する場合に便利です。ワークロードの指標に基づいて dfuse に必要なリソース数を把握したら、適切な上限を設定できます。

  • Autopilot クラスタでは、値 0 を使用してサイドカー コンテナのリソース上限とリクエストの設定を解除することはできません。Autopilot クラスタでサイドカー コンテナに大きなリソース上限を明示的に設定し、 Google Cloud 指標に基づいてリソース上限の増加が必要かどうかを判断する必要があります。