Amazon EFS のパフォーマンス問題のトラブルシューティング
一般的に、Amazon EFS で解決できない問題が発生した場合は、最新の Linux カーネルを使用していることを確認します。エンタープライズ Linux ディストリビューションを使用している場合は、以下をお勧めします。
-
Amazon Linux 2 (カーネル 4.3 以降)
-
Amazon Linux 2015.09 以降
-
RHEL 7.3 以降
-
Ubuntu 16.04 のすべてのバージョン
-
カーネル 3.13.0-83 の Ubuntu 14.04 以降
-
SLES 12 Sp2 以降
別のディストリビューションまたはカスタムカーネルを使用している場合は、カーネルバージョン 4.3 以降をお勧めします。
注記
多くのファイルを並列に開くとパフォーマンスが低下する により、RHEL 6.9 は特定のワークロードには適していない可能性があり ます。
トピック
EFS ファイルシステムを作成できない
EFS ファイルシステムの作成要求が失敗し、次のメッセージが表示されます。
User: arn:aws:iam::111122223333:user/
username
is not authorized to perform: elasticfilesystem:CreateFileSystem on the specified resource.
実行するアクション
AWS Identity and Access Management (IAM) ポリシーで確認し、指定したリソース条件で EFS ファイルシステムを作成する権限があることを確認します。詳細については、「Amazon EFS のためのアイデンティティとアクセス管理」を参照してください。
NFS ファイルシステム上の許可されたファイルへのアクセスが拒否されました
16 を超えるアクセスグループ ID (GID) が割り当てられたユーザーが NFS ファイルシステムでオペレーションを実行しようとすると、ファイルシステム上の許可されたファイルへのアクセスが拒否される場合があります。この問題は、NFS プロトコルがユーザー 1 人あたり最大 16 の GID をサポートし、RFC 5531
実行するアクション
各ユーザーに割り当てられるアクセスグループ (GID) の数が 16 を超えないように、NFS ユーザーとグループのマッピングを再構築してください。
Amazon EFS コンソールにアクセスするときにエラーが発生しました
このセクションでは、Amazon EFS 管理コンソールにアクセスしたときにユーザーが発生する可能性のあるエラーについて説明します。
ec2:DescribeVPCs
の認証情報の認証中にエラーが発生しました
Amazon EFS コンソールにアクセスすると、次のエラーメッセージが表示されます。
AuthFailure: An error occurred authenticating your credentials for ec2:DescribeVPCs.
このエラーは、ログイン認証情報が Amazon EC2 サービスで正常に認証されなかったことを示します。Amazon EFS コンソールは、選択した VPC に EFS ファイルシステムを作成するときに、ユーザーに代わって Amazon EC2 サービスを呼び出します。
実行するアクション
クライアントが Amazon EFS コンソールにアクセスする時間が正しく設定されていることを確認します。
Amazon EC2 インスタンスがハングする
ファイルシステムをアンマウントせずにファイルシステムのマウントターゲットを削除したため、Amazon EC2 インスタンスがハングすることがあります。
実行するアクション
ファイルシステムのマウントターゲットを削除する前に、ファイルシステムをアンマウントします。Amazon EFS ファイルシステムのアンマウントの詳細については、ファイルシステムをアンマウントする を参照してください。
大量のデータを書き込みしているアプリケーションがハングする
Amazon EFS に大量のデータを書き込むアプリケーションがハングし、インスタンスが再起動します。
実行するアクション
アプリケーションが Amazon EFS にすべてのデータを書き込む時間が長すぎる場合、プロセスが応答しなくなったように見えるため、Linux が再起動することがあります。この動作は、kernel.hung_task_panic
と kernel.hung_task_timeout_secs
という 2 つのカーネルの設定パラメータにより定義されます。
次の例では、停止したプロセスの状態は ps
コマンドにより D
と共にインスタンスの再起動より前に報告されます。これは、プロセスが I/O で待機していることを示します。
$ ps aux | grep large_io.py root 33253 0.5 0.0 126652 5020 pts/3 D+ 18:22 0:00 python large_io.py /efs/large_file
再起動を避けるには、タイムアウト時間を長くするか、またはハングタスクが検出されたときのカーネルパニックを無効にします。次のコマンドは、ほとんどの Linux システムでタスクがハングしたときのカーネルパニックを無効にします。
$ sudo sysctl -w kernel.hung_task_panic=0
多くのファイルを並列に開くとパフォーマンスが低下する
複数のファイルを並列に開くアプリケーションでは、I/O の並列化のパフォーマンスが期待されるほど向上しません。
実行するアクション
この問題は、Network File System バージョン4 (NFSv4) クライアントおよび NFSv4.1 を使用する RHEL 6 クライアントで発生します。これらの NFS クライアントは NFS OPEN および CLOSE 操作をシリアル化するためです。NFSプロトコルバージョン 4.1 と、この問題が発生しない Linux ディストリビューションの 1 つを使用してください。
NFSv4.1 を使用できない場合は、Linux NFSv4.0 クライアントによりユーザー ID とグループ ID によるオープンとクローズのリクエストが直列化することに注意してください。この直列化は、複数のプロセスまたは複数のスレッドが同時にリクエストを発行した場合でも発生します。クライアントは、すべての ID が一致したときに、NFS サーバーに一度に 1 つのオープンまたはクローズの操作を送信します。これらの問題を回避するには、次のいずれかの操作を実行します。
-
同じプロセスを、同じ Amazon EC2 インスタンス上の異なるユーザー ID から実行できます。
-
すべてのオープンリクエストでユーザー ID を同じにしておき、代わりにグループ ID のセットを変更することができます。
-
別の Amazon EC2 インスタンスから各プロセスを実行できます。
カスタム NFS 設定による書き込みの遅延
カスタム NFS クライアント設定があり、Amazon EC2 インスタンスがファイルシステムで別の Amazon EC2 インスタンスから実行された書き込み操作を参照するのに最大 3 秒かかります。
実行するアクション
この問題が発生した場合は、次のいずれかの方法で解決することができます。
-
データを読み取っている Amazon EC2 インスタンスの NFS クライアントが属性のキャッシュを有効にしている場合は、ファイルシステムをアンマウントします。次に、属性のキャッシュを無効にするため、
noac
オプションを使用して再マウントします。NFSv4.1 では、属性のキャッシュはデフォルトで有効になっています。注記
クライアント側のキャッシュを無効にすると、アプリケーションのパフォーマンスを低下させる可能性があります。
-
NFS プロシージャと互換性のあるプログラミング言語を使用して、必要に応じて属性のキャッシュをクリアすることもできます。これを行うには、読み込みリクエストの直前に
ACCESS
プロシージャリクエストを送信します。たとえば、Python プログラミング言語を使用して、以下の呼び出しを作成できます。
# Does an NFS ACCESS procedure request to clear the attribute cache, given a path to the file import os os.access(path, os.W_OK)
Oracle Recovery Manager を使用したバックアップの作成に時間がかかる
バックアップジョブを開始する前に Oracle Recovery Manager が 120 秒間一時停止すると、Oracle Recovery Manager を使用したバックアップの作成が遅くなることがあります。
実行するアクション
この問題が発生した場合は、Oracle ヘルプセンターにある「NFS の Direct NFS クライアントコントロールの有効化と無効化
注記
Amazon EFS では、Oracle Direct NFS はサポートされていません。