このページの一部またはすべての情報は、S3NS の Trusted Cloud に適用されない場合があります。

パフォーマンス調整のベストプラクティス

このページでは、Cloud Storage FUSE の主な機能と構成を使用して Cloud Storage FUSE を改善し、特にトレーニング、サービング、チェックポイントなどの AI / ML ワークロードで最大スループットと最適なパフォーマンスを実現する方法について説明します。

考慮事項

このページで推奨する構成を適用する前に、次の点を考慮してください。

このページで推奨される構成は、次の 3 つの方法で適用できます。
- Cloud Storage FUSE 構成ファイル
- Cloud Storage FUSE CLI オプション
- Google Kubernetes Engine のみ: Google Kubernetes Engine の YAML ファイルのサンプル
最新バージョンの Cloud Storage FUSE を実行していることを確認します。推奨構成は、Cloud Storage FUSE バージョン 3.0 以降と、GKE クラスタバージョン 1.32.2-gke.1297001 以降で実行される Google Kubernetes Engine 用 Cloud Storage FUSE CSI ドライバにのみ適用する必要があります。
推奨構成では、ジョブの期間にわたって Cloud Storage メタデータがキャッシュに保存されます。ファイルシステムの初回マウント後にチェックされません。そのため、最適なパフォーマンスを得るには、ファイルシステムを読み取り専用にするか、ファイルシステムのセマンティクスを write-to-new アプリケーション（常に新しいファイルに書き込むアプリケーション）にすることをおすすめします。次の AI / ML ワークロードは write-to-new です。
- チェックポインティング
- トレーニング
- サービング
- jax.jit() キャッシュ保存
このページの推奨構成は、大量のメモリと高帯域幅のネットワークインターフェースがある Cloud GPU と Cloud TPU の大規模なマシンタイプで検証されています。Cloud GPU と Cloud TPU のマシンタイプは、ホストノード構成内の CPU、メモリ、ローカルストレージなどの使用可能なリソースの数で異なる場合があります。これは、次のような構成のパフォーマンスに直接影響する可能性があります。
- A3 Ultra
- A3 Mega - 1.8 TiB メモリ、6 TiB LSSD
- Cloud TPU v5e - 188 GiB のメモリ（LSSD なし）
- Cloud TPU v5p - 448 GiB のメモリ、LSSD なし
- Cloud TPU v6（Trillium）- 1.5 TiB メモリ、LSSD なし

階層型名前空間が有効なバケットを使用する

常に階層型名前空間が有効になっているバケットを使用します。階層名前空間を使用すると、データが階層型ファイルシステム構造に整理され、バケット内のオペレーション効率が向上します。これにより、レスポンス時間が短縮され、オペレーションごとの全体的なリスト呼び出しが減少します。

階層型名前空間には次の利点があります。

階層型名前空間を使用するバケットでは、フラットバケットと比較して、初期の秒間クエリ数（QPS）が最大 8 倍になります。階層名前空間は、初期のオブジェクト読み取りリクエストを 1 秒あたり 40,000 件、初期のオブジェクト書き込みリクエストを 8,000 件サポートします。これは、一般的な Cloud Storage FUSE フラットバケット（初期のオブジェクト読み取りリクエストが 1 秒あたり 5,000 件、初期のオブジェクト書き込みリクエストが 1,000 件）よりも大幅に多い数です。
階層型名前空間は、Cloud Storage FUSE でチェックポイントを作成してアトミック性を確保するために必要なアトミックなディレクトリ名の変更を提供します。階層型名前空間が有効になっているバケットを使用すると、大規模なチェックポインティングで特にメリットがあります。これは、ML フレームワークがディレクトリ名の変更を使用してチェックポイントを確定するためです。ディレクトリ名の変更は高速なアトミックコマンドであり、階層型名前空間が有効になっているバケットでのみサポートされています。階層型名前空間が有効になっているバケットを使用しない場合は、非 HNS バケットの名前変更の上限を引き上げるをご覧ください。

階層型名前空間が有効なバケットを作成する方法については、階層型名前空間が有効なバケットを作成するをご覧ください。階層名前空間が有効になっているバケットをマウントする方法については、階層名前空間が有効になっているバケットをマウントするをご覧ください。階層型名前空間は、Google Kubernetes Engine バージョン 1.31.1-gke.2008000 以降でサポートされています。

ディレクトリ固有のマウントを実行する

バケット内の特定のディレクトリにアクセスする場合は、バケット全体をマウントするのではなく、only-dir マウントオプションを使用して特定のディレクトリのみをマウントできます。ディレクトリ固有のマウントを行うと、ファイル名を解決するときにトラバースするディレクトリの数が制限されるため、リスト呼び出しが高速化され、リスト呼び出しと stat 呼び出しの合計数が少なくなります。これは、LookUpInode 呼び出しとバケットまたはディレクトリアクセスリクエストによって、パス内の各ファイルまたはディレクトリに対してリスト呼び出しと stat 呼び出しが自動的に生成されるためです。

特定のディレクトリをマウントするには、次のいずれかの方法を使用します。

Google Kubernetes Engine

Google Kubernetes Engine 用 Cloud Storage FUSE CSI ドライバで次のマウント構成を使用します。

volumeHandle: BUCKET_NAME

only-dir:DIRECTORY_NAME

ここで

BUCKET_NAME は、ディレクトリをマウントするバケットの名前です。
DIRECTORY_NAME は、マウントするディレクトリの名前です。

Compute Engine

gcsfuse --only-dir コマンドを実行して、Compute Engine 仮想マシン上の特定のディレクトリをマウントします。

gcsfuse --only-dir DIRECTORY_NAME BUCKET_NAME MOUNT_POINT

ここで

BUCKET_NAME は、ディレクトリをマウントするバケットの名前です。
DIRECTORY_NAME は、マウントするディレクトリの名前です。
MOUNT_POINT は、バケットがマウントされるローカルディレクトリです。例: /path/to/mount/point

ディレクトリマウントの実行方法の詳細については、バケット内のディレクトリをマウントするをご覧ください。

メタデータキャッシュ値を増やす

繰り返し読み取りのパフォーマンスを向上させるには、大量のメタデータをキャッシュに保存し、メタデータの有効期限をバイパスするように Cloud Storage FUSE を構成します。これにより、Cloud Storage へのメタデータリクエストの繰り返しを回避し、パフォーマンスを大幅に向上させることができます。

メタデータキャッシュの値を増やすと、繰り返し読み取りを行うワークロードで Cloud Storage の呼び出しの繰り返しを回避できます。これは、無限の TTL を設定できる読み取り専用ボリュームでメリットがあります。

メタデータキャッシュの値を増やす前に、次の点を考慮してください。

有効期間（TTL）を無限に設定できるのは、読み取り専用または新規書き込み専用のボリュームのみです。
メタデータキャッシュは、各ノードの指定されたマウントポイントのすべてのメタデータをキャッシュに保存し、Cloud Storage への追加アクセスを不要にするため、メモリ構成が大きいノードでのみ有効にし、大幅にサイズを増やす必要があります。
このセクションの構成では、アクセスされたすべてのメタデータが無限の TTL でキャッシュに保存されます。これにより、他のクライアントが同じ Cloud Storage バケットで変更（ファイルのオーバーライドやファイルの削除など）を行うと、整合性の保証に影響する可能性があります。
メモリ消費量が影響を受けないことを確認するには、メタデータキャッシュで使用されるメモリ量が許容範囲内であることを検証します。このメモリ量は、マウントされたバケット内のファイル数と使用されているマウントポイントの数によって異なり、ギガバイト単位まで増加する可能性があります。たとえば、各ファイルのメタデータは約 1.5 KiB のメモリを使用します。また、100 万個のファイルのメタデータは約 1.5 GiB のメモリを使用します。詳細については、キャッシュ保存の概要をご覧ください。

次の手順で、大量のメタデータをキャッシュに保存し、メタデータの有効期限をバイパスするように Cloud Storage FUSE を構成します。

CLI オプション

gcsfuse --metadata-cache-ttl-secs=-1 \
      --stat-cache-max-size-mb=-1 \
      --type-cache-max-size-mb=-1 \
      BUCKET_NAME MOUNT_POINT

ここで

BUCKET_NAME はバケットの名前です。
MOUNT_POINT は、バケットがマウントされるローカルディレクトリです。例: /path/to/mount/point

構成ファイル

metadata-cache:
stat-cache-max-size-mb: -1
ttl-secs: -1
type-cache-max-size-mb: -1

Google Kubernetes Engine

  mountOptions:
      - metadata-cache:ttl-secs:-1
      - metadata-cache:stat-cache-max-size-mb:-1
      - metadata-cache:type-cache-max-size-mb:-1

Compute Engine

gcsfuse --metadata-cache-ttl-secs=-1 \
      --stat-cache-max-size-mb=-1 \
      --type-cache-max-size-mb=-1 \
      BUCKET_NAME MOUNT_POINT

ここで

BUCKET_NAME はバケットの名前です。
MOUNT_POINT は、バケットがマウントされるローカルディレクトリです。例: /path/to/mount/point

メタデータキャッシュに事前入力する

ワークロードを実行する前に、メタデータキャッシュを事前入力することをおすすめします。これにより、パフォーマンスが大幅に向上し、特に implicit-dirs 構成オプションを使用している場合は、Cloud Storage へのメタデータ呼び出しの数が大幅に削減されます。GKE 用 Cloud Storage FUSE CSI ドライバは、メタデータキャッシュの事前入力処理を行う API を提供します。メタデータプリフェッチを使用してメタデータキャッシュに事前入力するをご覧ください。

メタデータキャッシュに事前入力するには、次のいずれかの方法を使用します。

Google Kubernetes Engine

gcsfuseMetadataPrefetchOnMount CSI ボリューム属性フラグを true に設定します。

Google Kubernetes Engine バージョン 1.32.1-gke.1357001 以降では、PersistentVolume 定義の volumeAttributes フィールドで gcsfuseMetadataPrefetchOnMount 構成オプションを使用し、特定のボリュームのメタデータプリフェッチを有効にできます。gcsfuseMetadataPrefetchOnMount 構成オプションを使用する場合、initContainer メソッドは必要ありません。

  apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: training-bucket-pv
  spec:
    ...
    csi:
      volumeHandle: BUCKET_NAME
      volumeAttributes:
        ...
        gcsfuseMetadataPrefetchOnMount: "true"

ここで

BUCKET_NAME はバケットの名前です。

初期化コンテナのリソースは、バケットの内容と階層レイアウトによって異なる場合があります。上限を引き上げるには、カスタムメタデータプリフェッチサイドカーリソースの設定を検討してください。

Linux

Cloud Storage FUSE マウントポイントで ls -R コマンドを手動で実行し、すべてのファイルを再帰的に一覧取得してメタデータキャッシュを事前入力します。

ls -R MOUNT_POINT > /dev/null

ここで

MOUNT_POINT: Cloud Storage FUSE マウントポイントのパス。

Compute Engine

ls -R MOUNT_POINT > /dev/null

ここで

MOUNT_POINT: Cloud Storage FUSE マウントポイントのパス。

ファイルキャッシュと並列ダウンロードを有効にする

ファイルキャッシュを使用すると、頻繁にアクセスされるファイルデータをマシンにローカルに保存できるため、繰り返しの読み取りが高速化され、Cloud Storage の費用が削減されます。ファイルキャッシュを有効にすると、並列ダウンロードも自動的に有効になります。並列ダウンロードでは、ファイルキャッシュディレクトリをプリフェッチバッファとして使用して、複数のワーカーでファイルを並列にダウンロードします。これにより、モデルの読み込み時間が 9 倍速くなります。

ファイルのキャッシュ保存と並列ダウンロードを有効にして構成する方法については、ファイルのキャッシュ保存の動作を有効にして構成するをご覧ください。サンプル構成を使用するには、ファイルのキャッシュ保存と並列ダウンロードを有効にするサンプル構成をご覧ください。

ファイルキャッシュと並列ダウンロードを使用する場合の Cloud GPU と Cloud TPU の考慮事項

ファイルキャッシュは、次のガイダンスに従って、ローカル SSD、RAM、Persistent Disk、Google Cloud Hyperdisk でホストできます。いずれの場合も、データまたは個々の大きなファイルは、max-size-mb 構成を使用して制御されるファイルキャッシュディレクトリの使用可能な容量内に収まるサイズでなければなりません。

Cloud GPU の考慮事項

ローカル SSD は、トレーニングデータとチェックポイントのダウンロードに最適です。Cloud GPU マシンタイプには、使用可能な SSD 容量が含まれています。たとえば、12 TiB の SSD を含む A4 マシンタイプなどです。

RAM ディスクは、システムの未使用の RAM の量と比較してサイズが小さいため、モデルの重みを読み込むのに最適なパフォーマンスを提供します。
Persistent Disk と Google Cloud Hyperdisk はどちらもキャッシュとして使用できます。

Cloud TPU の考慮事項

Cloud TPU はローカル SSD をサポートしていません。Cloud TPU でファイルキャッシュを修正せずに使用すると、デフォルトで使用される場所はブートボリュームになります。これは推奨されず、パフォーマンスの低下につながります。

ブートボリュームの代わりに、パフォーマンスが優れており、追加費用もかからない RAM ディスクを使用することをおすすめします。ただし、RAM ディスクはサイズが制限されることが多く、チェックポイントのサイズと使用可能な RAM に応じて、モデルの重み付けやチェックポイントのダウンロードに最も役立ちます。また、キャッシュ保存には Persistent Disk と Google Cloud Hyperdisk を使用することをおすすめします。

ファイルキャッシュと並列ダウンロードを有効にする構成例

デフォルトでは、Google Kubernetes Engine ノードで ephemeral-storage-local-ssd モードが有効になっている場合、ファイルキャッシュはローカル SSD を使用します。ローカル SSD が使用できない場合（Cloud TPU マシンなど）、ファイルキャッシュは Google Kubernetes Engine ノードのブートディスクを使用します。これはおすすめしません。この場合、RAM ディスクをキャッシュディレクトリとして使用できますが、ファイルキャッシュ保存に使用できる RAM の量と Pod で必要な RAM の量を考慮してください。

CLI オプション

gcsfuse --file-cache-max-size-mb: -1 \
      --file-cache-cache-file-for-range-read: true \
      --file-cache-enable-parallel-downloads: true \
      BUCKET_NAME

ここで

BUCKET_NAME はバケットの名前です。

構成ファイル

file-cache:
  max-size-mb: -1
  cache-file-for-range-read: true
  enable-parallel-downloads: true

Cloud GPU

mountOptions:
    - file-cache:max-size-mb:-1
    - file-cache:cache-file-for-range-read:true
    - file-cache:enable-parallel-downloads:true

# RAM disk file cache if LSSD not available. Uncomment to use
# volumes:
#   - name: gke-gcsfuse-cache
#     emptyDir:
#       medium: Memory

Cloud TPU

mountOptions:
    - file-cache:max-size-mb:-1
    - file-cache:cache-file-for-range-read:true
    - file-cache:enable-parallel-downloads:true

volumes:
    - name: gke-gcsfuse-cache
      emptyDir:
        medium: Memory

Compute Engine

gcsfuse --file-cache-max-size-mb: -1 \
      --file-cache-cache-file-for-range-read: true \
      --file-cache-enable-parallel-downloads: true \
      BUCKET_NAME MOUNT_POINT

ここで

BUCKET_NAME はバケットの名前です。
MOUNT_POINT は、バケットがマウントされるローカルディレクトリです。例: /path/to/mount/point

ネガティブ統計情報キャッシュのエントリを無効にする

デフォルトでは、Cloud Storage FUSE はネガティブ統計情報エントリ（存在しないファイルのエントリ）を 5 秒の TTL でキャッシュに保存します。分散チェックポイントなどのように、ファイルが頻繁に作成または削除されるワークロードでは、これらのキャッシュエントリがすぐに古くなり、パフォーマンスの問題につながる可能性があります。これを回避するには、negative-ttl-secs 構成オプションを使用して、トレーニング、サービング、チェックポインティングワークロードのネガティブ統計情報キャッシュを無効にすることをおすすめします。

ネガティブ統計情報キャッシュを無効にするには、次の手順を行います。

CLI オプション

gcsfuse --metadata-cache-negative-ttl-secs: 0 \
  BUCKET_NAME

ここで

BUCKET_NAME はバケットの名前です。

構成ファイル

metadata-cache:
 negative-ttl-secs: 0

Google Kubernetes Engine

mountOptions:
    - metadata-cache:negative-ttl-secs:0

Compute Engine

gcsfuse --metadata-cache-negative-ttl-secs: 0 \
  BUCKET_NAME MOUNT_POINT

ここで

BUCKET_NAME はバケットの名前です。
MOUNT_POINT は、バケットがマウントされるローカルディレクトリです。例: /path/to/mount/point

ストリーミング書き込みを有効にする

ストリーミング書き込みでは、データが書き込まれると同時に Cloud Storage に直接アップロードされるため、レイテンシとディスク容量の使用量が削減されます。これは、チェックポイントなどの大規模なシーケンシャル書き込みに特に有効です。Cloud Storage FUSE バージョン 3.0 以降では、ストリーミング書き込みがデフォルトで有効になっています。

ストリーミング書き込みがデフォルトで有効になっていない場合は、次の手順で有効にします。ストリーミング書き込みを有効にするには、Google Kubernetes Engine バージョン 1.32.1-gke.1729000 以降で使用可能な Cloud Storage FUSE バージョン 3.0 が必要です。

CLI オプション

gcsfuse --enable-streaming-writes: true \
  BUCKET_NAME

ここで

BUCKET_NAME はバケットの名前です。

構成ファイル

write:
 enable-streaming-writes: true

Google Kubernetes Engine

mountOptions:
    - write:enable-streaming-writes:true

Compute Engine

gcsfuse --enable-streaming-writes: true \
  BUCKET_NAME MOUNT_POINT

ここで

BUCKET_NAME はバケットの名前です。
MOUNT_POINT は、バケットがマウントされるローカルディレクトリです。例: /path/to/mount/point

カーネルの先読みサイズを増やす

サービングやチェックポイントの復元など、主に大規模なファイルの順次読み取りが含まれるワークロードでは、先読みサイズを増やすとパフォーマンスが大幅に向上します。これには、ローカルマシンの read_ahead_kb Linux カーネルパラメータを使用します。ほとんどの Linux ディストリビューションで設定されているデフォルトの 128 KB ではなく、read_ahead_kb カーネルパラメータを 1 MB に増やすことをおすすめします。Compute Engine インスタンスの場合、カーネルパラメータを正常に増やすには、sudo 権限または root 権限が必要です。

特定の Cloud Storage FUSE でマウントされたディレクトリの read_ahead_kb カーネルパラメータを 1 MB に増やすには、次の操作を行います。コマンドを実行する前に、バケットを Cloud Storage FUSE にマウントする必要があります。マウントしないと、カーネルパラメータは増加しません。

Google Kubernetes Engine

mountOptions:


read_ahead_kb=1024

Compute Engine

export MOUNT_POINT=/path/to/mount/point
echo 1024 | sudo tee /sys/class/bdi/0:$(stat -c "%d" $MOUNT_POINT)/read_ahead_kb

ここで

MOUNT_POINT: Cloud Storage FUSE マウントポイントのパス。

重複するチェックを回避するために Security Token Service を無効にする

Google Kubernetes Engine 用 Cloud Storage FUSE CSI ドライバでは、バケットと GKE サービスアカウント間の Workload Identity バインディングのユーザーによる誤構成が原因で Pod の復元可能性が損なわれることを防ぐため、アクセスチェックを実行します。これは、大規模なデフォルトの Security Token Service API 割り当てに影響する可能性があります。この機能は、Persistent Volume CSI ドライバの skipCSIBucketAccessCheck ボリューム属性を設定することで無効にできます。Pod のマウントエラーを回避するため、GKE サービスアカウントがターゲットの Cloud Storage バケットに適切なアクセス権を持っていることを確認することをおすすめします。

また、Google Kubernetes Engine クラスタが 6,000 個を超えるノードで構成されている場合は、Security Token Service の割り当てをデフォルト値の 6000 より大きくする必要があります。大規模なデプロイで割り当てを増やさないと、429 エラーが発生する可能性があります。Security Token Service の割り当ては、割り当てと上限のページで増やす必要があります。割り当てはマウント数と同じにすることをおすすめします。たとえば、クラスタに 10,000 個のマウントがある場合は、割り当てを 10000 に増やします。

skipCSIBucketAccessCheck ボリューム属性を設定するには、次の構成例をご覧ください。

  volumeAttributes:
      - skipCSIBucketAccessCheck: "true"

パフォーマンスに関するその他の考慮事項

前述の主な最適化以外にも、Cloud Storage FUSE の全体的なパフォーマンスに大きな影響を与える要因がいくつかあります。以降のセクションでは、Cloud Storage FUSE を使用する際におすすめするパフォーマンスに関するその他の考慮事項について説明します。

HNS 以外のバケットの名前変更の上限を引き上げる

チェックポインティングワークロードは、アトミックで高速な名前変更と、読み取りと書き込みの QPS の増加により、常に階層型名前空間が有効になっているバケットで行う必要があります。ただし、ディレクトリ名の変更がアトミックではなく、時間がかかるというリスクを許容する場合は、階層名前空間のないバケットを使用してチェックポインティングを実行するときに rename-dir-limit 構成オプションを使用できます。このオプションを使用すると、任意の時点でディレクトリ名の変更オペレーションに関与するファイルまたはオペレーションの数の上限を指定できます。

チェックポインティングの失敗を防ぐため、rename-dir-limit 構成オプションを大きな値に設定することをおすすめします。Cloud Storage FUSE はフラットな名前空間を使用し、オブジェクトは不変であるため、ディレクトリ名の変更オペレーションでは、ディレクトリ内のすべての個々のファイルの名前変更と削除が行われます。rename-dir-limit 構成オプションを設定すると、名前変更オペレーションの影響を受けるファイル数を制御できます。

次の手順で rename-dir-limit 構成オプションを設定します。

CLI オプション

gcsfuse --rename-dir-limit: 200000 \
  BUCKET_NAME

ここで

BUCKET_NAME はバケットの名前です。

構成ファイル

file-system:
 rename-dir-limit: 200000

Google Kubernetes Engine

mountOptions:
    - rename-dir-limit=200000

Compute Engine

gcsfuse --rename-dir-limit: 200000 \
  BUCKET_NAME MOUNT_POINT

ここで

BUCKET_NAME はバケットの名前です。
MOUNT_POINT は、バケットがマウントされるローカルディレクトリです。例: /path/to/mount/point

カーネルリストのキャッシュ保存

リストキャッシュは、ディレクトリとファイルリスト、または ls のレスポンス用のキャッシュです。これにより、リストオペレーションの速度が向上します。Cloud Storage FUSE によって管理される統計情報キャッシュや型キャッシュとは異なり、リストキャッシュはカーネルのページキャッシュに保持され、メモリの可用性に基づいてカーネルによって制御されます。

カーネルリストキャッシュ保存を有効にすると、次のユースケースで最も効果的です。

ディレクトリリストを繰り返すワークロード: この構成は、AI / ML トレーニングの実行など、ディレクトリ全体の一覧取得を頻繁に行うワークロードに特に有効です。これは、サービングワークロードとトレーニングワークロードの両方にメリットがあります。
読み取り専用マウント: 整合性の問題を回避するため、読み取り専用マウントとともにリストキャッシュ保存を使用することをおすすめします。

カーネルリストのキャッシュ保存を有効にする場合は注意が必要です。この機能は、ファイルシステムが真に読み取り専用であり、ジョブの実行中にディレクトリの内容が変更されない場合にのみ使用してください。これは、このフラグを使用すると、特に TTL が -1 に設定されている場合、ローカルアプリケーションで更新が認識されないためです。

たとえば、クライアント 1 が directoryA をリストすると、directoryA がカーネルリストキャッシュに常駐します。クライアント 2 は、Cloud Storage バケットの directoryA の下に fileB を作成します。クライアント 1 は directoryA の fileB を継続的にチェックします。これは基本的にカーネルリストのキャッシュエントリをチェックするもので、ネットワークを介して行われることはありません。クライアント 1 は、ファイルのリストがローカルカーネルリストキャッシュから継続的に提供されるため、新しいファイルがディレクトリにあることを認識しません。クライアント 1 がタイムアウトし、プログラムが中断されます。

リストキャッシュを有効にするには、次の操作を行います。

CLI オプション

gcsfuse --kernel-list-cache-ttl-secs: -1 \
  BUCKET_NAME

ここで

BUCKET_NAME はバケットの名前です。

構成ファイル

file-system:
 kernel-list-cache-ttl-secs: -1

Google Kubernetes Engine

mountOptions:
    - file-system:kernel-list-cache-ttl-secs:-1

Compute Engine

gcsfuse --kernel-list-cache-ttl-secs: -1 \
  BUCKET_NAME MOUNT_POINT

ここで

BUCKET_NAME はバケットの名前です。
MOUNT_POINT は、バケットがマウントされるローカルディレクトリです。例: /path/to/mount/point

file-system:kernel-list-cache-ttl-secs マウントオプションを使用する場合、値は次の意味を持ちます。

正の値は、ディレクトリリストレスポンスをカーネルのページキャッシュに保持する TTL（秒単位）を表します。
-1 の値を指定すると、エントリの有効期限がバイパスされ、キャッシュから利用可能な場合に、キャッシュからリストレスポンスが返されます。

Cloud Storage FUSE で JAX 永続コンパイル（JIT）キャッシュを使用する

JAX は、コンパイルされた関数アーティファクトを保存するオプションの永続コンパイルキャッシュである、ジャストインタイム（JIT）キャッシュをサポートしています。このキャッシュを使用すると、冗長なコンパイルステップを回避できるため、後続のスクリプト実行を大幅に高速化できます。

JIT キャッシュを有効にするには、次の要件を満たす必要があります。

最新バージョンの JAX を使用する: 最新のキャッシュ機能と最適化には、JAX バージョン 0.5.1 以降を使用します。
キャッシュ容量を最大化する: キャッシュの削除によるパフォーマンスの低下を防ぐため、特にデフォルト設定をオーバーライドする場合は、キャッシュサイズを無制限に設定することを検討してください。これを行うには、環境変数を設定します。
```
export JAX_COMPILATION_CACHE_MAX_SIZE=-1
```
チェックポイント Pod の YAML を確認する: JAX JIT キャッシュのマウントポイントにチェックポイント構成を使用します。

次のステップ

サンプルの Google Kubernetes Engine YAML ファイルを使用して、調整のベストプラクティスを構成する。
Cloud Storage FUSE 構成ファイルのオプションの詳細を確認する。
Cloud Storage FUSE CLI オプションの詳細を確認する。

パフォーマンス調整のベスト プラクティス

考慮事項

階層型名前空間が有効なバケットを使用する

ディレクトリ固有のマウントを実行する

Google Kubernetes Engine

Compute Engine

メタデータ キャッシュ値を増やす

CLI オプション

構成ファイル

Google Kubernetes Engine

Compute Engine

メタデータ キャッシュに事前入力する

Google Kubernetes Engine

Linux

Compute Engine

ファイル キャッシュと並列ダウンロードを有効にする

ファイル キャッシュと並列ダウンロードを使用する場合の Cloud GPU と Cloud TPU の考慮事項

Cloud GPU の考慮事項

Cloud TPU の考慮事項

ファイル キャッシュと並列ダウンロードを有効にする構成例

CLI オプション

構成ファイル

Cloud GPU

Cloud TPU

Compute Engine

ネガティブ統計情報キャッシュのエントリを無効にする

CLI オプション

構成ファイル

Google Kubernetes Engine

Compute Engine

ストリーミング書き込みを有効にする

CLI オプション

構成ファイル

Google Kubernetes Engine

Compute Engine

カーネルの先読みサイズを増やす

Google Kubernetes Engine

Compute Engine

重複するチェックを回避するために Security Token Service を無効にする

パフォーマンスに関するその他の考慮事項

HNS 以外のバケットの名前変更の上限を引き上げる

CLI オプション

構成ファイル

Google Kubernetes Engine

Compute Engine

カーネルリストのキャッシュ保存

CLI オプション

構成ファイル

Google Kubernetes Engine

Compute Engine

Cloud Storage FUSE で JAX 永続コンパイル（JIT）キャッシュを使用する

次のステップ

パフォーマンス調整のベストプラクティス

メタデータキャッシュ値を増やす

メタデータキャッシュに事前入力する

ファイルキャッシュと並列ダウンロードを有効にする

ファイルキャッシュと並列ダウンロードを使用する場合の Cloud GPU と Cloud TPU の考慮事項

ファイルキャッシュと並列ダウンロードを有効にする構成例