Amazon EMR クラスターのコアノードがディスク容量不足になる原因を教えてください。
Amazon EMR クラスターで Apache Spark ジョブを実行していますが、コアノードのディスク容量がほとんどありません。
解決方法
どのコアノードに異常があるかを特定する
少なくとも 1 つの Amazon Elastic Block Store (Amazon EBS) ボリュームがアタッチされているノードは、ディスク使用率が 90% を超えると異常と見なされます。ディスク使用率が 90% に達した可能性があるノードを特定するには、次の操作を行います。
1. Amazon CloudWatch metric MRUnhealthyNodes を確認します。このメトリクスでは、EMR クラスター内の異常なノードの数を示しています。
注: CloudWatch アラームを作成して MRUnhealthyNodes メトリクスをモニタリングできます。
2. プライマリノードに接続し、/emr/instance-controller/log/instance-controller.log にあるインスタンスコントローラのログにアクセスします。インスタンスコントローラーのログで InstanceJointStatusMap を検索して、どのノードが異常であるかを特定します。
詳細については、「Amazon EMR の Spark で ExecutorLostFailure「スレーブが失われました」エラーを解決するにはどうすればよいですか ?」の「ディスク使用率が高い」を参照してください。
3. コアノードにログインし、次のコマンドを実行して、マウントの使用率が高いかどうかを確認します。
df -h
不要なローカルおよび一時的な Spark アプリケーションファイルを削除する
Spark ジョブを実行すると、Spark アプリケーションはコアノードの残りのディスク容量を消費するローカルファイルを作成します。df-h コマンドを実行し、たとえば /mnt が 90% を超えるディスク容量を使用していることが判明した場合は、どのディレクトリまたはファイルの使用率が高いかを確認してください。
コアノードで次のコマンドを実行して、ディスク容量が最も多く使用されている上位 10 のディレクトリが表示します。
cd /mnt sudo du -hsx * | sort -rh | head -10
/mnt/hdfs ディレクトリの使用率が高い場合は、HDFS の使用状況を確認し、ログファイルなどの不要なファイルを削除します。保存期間を短くすると、HDFS からログファイルを自動的に消去するのに役立ちます。
hdfs dfsadmin -report hadoop fs -du -s -h /path/to/dir
Spark イベントと YARN コンテナーログの保存期間を短縮する
HDFS 使用の一般的な原因は、/var/log ディレクトリです。/var/log ディレクトリには、Spark イベントログや YARN コンテナログなどのログファイルが格納されます。これらのファイルの保存期間を変更することで、容量を節約できます。
以下のコマンド例では、/var/log/spark の使用状況が表示します。
注: /var/log/spark はデフォルトの Spark イベントログディレクトリです。
hadoop fs -du -s -h /var/log/spark
Spark ジョブ履歴ファイルのデフォルトの保存期間を短縮する
Spark のジョブ履歴ファイルは、デフォルトで /var/log/spark/apps にあります。ファイルシステム履歴クリーナーが実行されると、Spark は 7 日を経過したジョブ履歴ファイルを削除します。デフォルトの保存期間を短縮するには、次の操作を行います。
実行中のクラスターでは:
2. /etc/spark/conf/spark-defaults.conf に次の値を追加または更新します。次の構成では、クリーナーは 12 時間ごとに実行されます。1 日以上経過した設定クリアファイル。spark.history.fs.cleaner.internval とspark.history.fs.cleaner.maxAge パラメーターで、この期間を個々のユースケースに合わせてカスタマイズできます。
------ spark.history.fs.cleaner.enabled true spark.history.fs.cleaner.interval 12h spark.history.fs.cleaner.maxAge 1d ------
3. Spark History Server を再起動します。
クラスターの起動中。
次の構成を使用します。spark.history.fs.cleaner.internval とspark.history.fs.cleaner.maxAge パラメーターで、個々のユースケースに合わせて期間をカスタマイズできます。
{ "Classification": "spark-defaults", "Properties": { "spark.history.fs.cleaner.enabled":"true", "spark.history.fs.cleaner.interval":"12h", "spark.history.fs.cleaner.maxAge":"1d" } }
これらのパラメーターの詳細については、Spark ドキュメントの「モニタリングとインストルメンテーション」を参照してください。
YARN コンテナログのデフォルトの保存期間を短縮する
Spark アプリケーションログ (Spark ジョブの YARN コンテナログ) は、コアノードの /var/log/hadoop-yarn/apps にあります。アプリケーションの実行が終了すると、Spark はこれらのログを HDFS に移動します。デフォルトでは、YARN はアプリケーションログを HDFS に 48 時間保持します。保持期間を短縮するには:
1. SSH を使用してプライマリ、コア、またはタスクノードに接続します。
2. Amazon EMR クラスター (プライマリノード、コアノード、およびタスクノード) の各ノードで /etc/hadoop/conf/yarn-site.xml ファイルを開きます。
3. すべてのノードで yarn.log-aggregation.retain-seconds プロパティの値を減らします。
4. ResourceManager デーモンを再起動します。詳細については、「Amazon EMR とアプリケーションプロセスの表示と再起動」を参照してください。
クラスターを再構成することで保持期間を短縮することもできます。詳細については、Reconfigure an instance group in a running cluster を参照してください。
/mnt/yarnの使用量を削減する
/mnt/yarn ディレクトリの使用率が高い場合は、ユーザーキャッシュの保持率を調整するか、ノードの EBS ボリュームをスケーリングします。詳細については、「Hadoop または Spark ジョブのユーザーキャッシュが Amazon EMR で、ディスク領域を使いすぎないようにする方法を教えてください。」を参照してください。
クラスターのサイズを変更する、または Amazon EMR をスケーリングする
コアノードを追加して HDFS スペースの問題を軽減します。また、HDFS ディレクトリ以外のディレクトリがいっぱいになった場合は、コアノードまたはタスクノードのいずれかを追加します。詳細については、クラスターリソースのスケーリングを参照してください。
既存のノードの EBS ボリュームを拡張したり、動的スケーリングスクリプトを使用したりすることもできます。詳細については、次を参照してください。
- Amazon EMR の Spark で「デバイスにスペースが残っていません」ステージの障害を解決するにはどうすればよいですか?
- Amazon EMR クラスターでストレージを動的にスケールアップする
関連情報
関連するコンテンツ
- 質問済み 6年前lg...
- 質問済み 5年前lg...
- 質問済み 1ヶ月前lg...
- AWS公式更新しました 2年前
- AWS公式更新しました 2年前
- AWS公式更新しました 2年前