NVIDIA GPU でアクセラレートされた EC2 Linux インスタンスで Xid エラーをトラブルシューティングする方法を教えてください?

所要時間3分
0

NVIDIA GPU で高速化された Amazon Elastic Compute Cloud (Amazon EC2) Linux インスタンスでアプリケーションを実行すると、アプリケーションがクラッシュし、システムログに GPU 固有の Xid エラーが見つかりました。GPU から診断情報を取得し、GPU 関連の Xid エラーをトラブルシューティングしたいと考えています。

簡単な説明

AWS では、GPU アクセラレーションを備えた複数の EC2 インスタンスファミリーを提供しています。GPU は、すべての GPU アクセラレーション EC2 インスタンスファミリーのゲストインスタンスに渡されます。これにより、GPU ハードウェアの全機能を使用できます。

解決策

nvidia-smi 診断の読み取りと解釈

nvidia-smi ツールを使用して、インスタンスに接続されている NVIDIA GPU の状態とパフォーマンスに関する統計と診断を取得します。NVIDIA GPU ドライバーは、深層学習 Amazon マシンイメージ (AMI) のすべてのバリアントを含め、このツールを自動的に提供します。任意の GPU インスタンスファミリーに NVIDIA GPU ドライバーをインストールする方法の詳細については、「Linux インスタンスへの NVIDIA ドライバーのインストール」を参照してください。

sudo nvidia-smi-q コマンドを実行して統計情報をクエリします。

メモリ統計の例

ECC Errors
        Volatile                              # Errors counted since last GPU driver reload
            SRAM Correctable            : 0
            SRAM Uncorrectable          : 0
            DRAM Correctable            : 0
            DRAM Uncorrectable          : 0
        Aggregate                             # Errors counted for the life of the GPU
            SRAM Correctable            : 0
            SRAM Uncorrectable          : 0
            DRAM Correctable            : 0
            DRAM Uncorrectable          : 0

すべての世代の NVIDIA GPU は、GPU ハードウェアの集約メモリ統計と揮発性メモリ統計を記録します。集約された ECC エラーカウンタは GPU の存続期間中持続することに注意してください。正の値は、インスタンスでハードウェアの問題や GPU の障害が発生していることを示すものではありません。正の値は過去のものである可能性があるため、変動の激しい指標を確認することが重要です。

ただし、揮発性 ECCエラーは、GPUドライバーが最後にリロードした時点からゼロから増加します。修正不可能な ECC エラーは、インスタンスの存続期間中に増加します。ECC エラーが激しい場合は、インスタンスを再起動するか、GPU をリセットする必要がある場合があります。インスタンスタイプと GPU の世代に応じて再起動すると、ページリタイアが開始されるか、不良メモリページの行の再マッピングが開始されます。

P3、P3dn、G4dn インスタンス

    Retired Pages
        Single Bit ECC              : 0
        Double Bit ECC              : 0
        Pending Page Blacklist      : No

初期世代の NVIDIA GPU では、ダイナミックページ廃止が採用されています。シングルビットエラーは一般的に問題ないので無視できます。GPU ファームウェアは 2 ビットエラーを識別します。

GPU ファームウェアが 2 ビットエラーを検出すると、GPU は処理を停止し、アプリケーションを突然終了させます。2 ビットエラーが発生すると、Xid エラーがオペレーティングシステム (OS) ログに記録され、保留中のページのブラックリストステータスは**[はい]**になります。これらのエラーを解決するには、インスタンスを再起動して不良メモリ位置を元に戻します。再起動後、保留中のページのブラックリスト[いいえ] にリセットされます。

**注:**エラーカウンターは GPU の存続期間中持続します。そのため、インスタンス起動時のカウンタが 0 以外の場合でも、アクティブなハードウェアの問題や GPU の障害を示すものではありません。

**P4d、P4de、G5、および G5g インスタンス **

    Remapped Rows
        Correctable Error                 : 0 # Can safely ignore.
        Uncorrectable Error               : 0 # If > 0, review system logs for Xid errors
        Pending                           : No # If Yes, an instance reboot or GPU reset is required.
        Remapping Failure Occurred        : No # Should always be No. If Yes, please stop/start the instance.

A100 と A10G の GPU を搭載した以降のインスタンスファミリーでは、行の再マッピングによってメモリエラーが分離され、解消されます。ダイナミックページ廃止と同様に、行の再マッピングにより、劣化した既知のメモリ位置の再利用が防止されます。行の再マッピングは、旧世代の GPU のページ廃止スキームに代わるものです。

修正可能なメモリエラーは無視できます。修正できないエラーがあると、エラーが発生したり、アプリケーションが突然終了したりする可能性があります。修正不可能なエラーは、Xid エラーとして OS システムログに記録されます。

修正不可能なエラーの後に再マッピング待ちの行がアクティブになった場合は、GPU をリセットして不良メモリ位置を元に戻す必要があります。インスタンスを再起動して GPU をリセットします。または、次のコマンドを実行して GPU を手動でリセットします:

sudo nvidia-smi -i <GPU UUID> -r

再マッピングが失敗した場合は、インスタンスを停止して起動します。インスタンスを停止して起動すると、GPU が正常な、新しい基盤となるホストにインスタンスが移行されます。

異常な GPU の検出

AWS は自動化を使用して定期的に診断を実行し、異常な GPU を検出します。ハードウェアエラーが原因で異常な状態にある GPU は、最終的に特定され、自動的に交換されます。

障害モード

すべての世代の NVIDIA GPU 用の GPU ドライバーは、エラーを Xid エラーとして OS システムログに書き込みます。これらのエラーの分類と説明については、NVIDIA ウェブサイトのXid エラーを参照してください。

以下の一般的な Xid エラーのリストには、問題を解決するためのベストプラクティスが記載されています:

**GPU の数が間違っている、または GPU がない **

以下のコマンドを実行します:

nvidia-smi —list-gpus | wc -l

コマンド出力で、接続されている GPU の数が、インスタンスタイプで予想される GPU の数と一致していることを確認します。GPU が見つからない場合は、インスタンスを停止して起動します

Xid 48: DBE が発生しました。
Xid 63: ページは正常に廃止されました。
Xid 64: エラーによりページの廃止に失敗しました。

上記のエラーは、ECC エラーが発生したことを示しています。この問題を解決するには、「GPU の数が間違っている、または GPU がない」セクションの手順を実行してください。

NVRM: Xid 79 (PCI:0000:00:00): GPU がバスから落ちました。

Xid 79 エラーは、インスタンスが基盤となる GPU との通信を失ったことを示します。この問題を解決するには、インスタンスを再起動します。再起動後も問題が解決しない場合は、インスタンスを停止して起動します

警告: infoROM は GPU 0000:00:00.0 で壊れています

infoROM 破損エラーは、GPU ファームウェアの一部が破損していることを示します。この問題を解決するには、インスタンスを再起動するか、GPU をリセットします。再起動後も問題が解決しない場合は、インスタンスを停止して起動します

NVRM: Xid 119 PCI:0000:00:00): GSP からの RPC 待ちのタイムアウト!
NVRM: Xid 120 PCI: 0000:00:00): GSP エラー: タスク 1 でエラーコードが発生しました...

上記のエラーは、GPU システムプロセッサ (GSP) がオンになっているときに発生します。GPU ドライバーまたはカーネルモジュール内でGSP がオフになっていることを確認します。

ベストプラクティス

  • 可能な場合は、最新のドライバーと CUDA ランタイムを使用してください。GPU ドライバーの新しいリリースでは、修正、改善、最適化が頻繁に導入されています。ただし、これらの更新には機能上の変更が含まれる場合があります。最初に、本番環境以外の GPU インスタンスでドライバーの更新を段階的にテストしてください。
  • ターボブーストを備えた一般的な x86 CPU と同様に、GPU には負荷に応じて動的に変化するコアとメモリのクロック速度があります。最高のパフォーマンスを得るには、GPU コアとメモリのクロック速度を常に最大速度に設定してください。詳しくは、「GPU 設定の最適化」を参照してください。
  • GSP をオフにします。最近のインスタンス世代では、NVIDIA GPU には GSP ファームウェア機能が搭載されています。GSP は GPU の初期化やその他の管理タスクをオフロードするように設計されています。詳細については、NVIDIA ウェブサイトの「GSP ファームウェアを無効にする」を参照してください。
  • Amazon CloudWatch エージェントを使用して GPU をモニタリングします。CloudWatch エージェントは、CloudWatch から収集してモニタリングできる NVIDIA GPU メトリクスをネイティブにサポートしています。詳細については、「 NVIDIA GPU メトリクスの収集」を参照してください。

AWS サポートに問い合わせる

インスタンス ID と nvidia-smi-q コマンドの出力をサポートケースに入力してください。

また、NVIDIA GPU ドライバーに含まれている sudo nvidia-bug-report.sh コマンドを実行してください。nvidia-bug-report.sh スクリプトは、主要なログやその他の診断情報をキャプチャします。このスクリプトは、現在の作業ディレクトリに nvidia-bug-report.log.gz という名前の圧縮ログファイルを作成します。このファイルを取得して AWS サポートに提供できます。

AWS公式
AWS公式更新しました 10ヶ月前
コメントはありません

関連するコンテンツ