E-MapReduce:よくある質問

ステートフルクラスターの再起動時に発生すること

ステートフルクラスターの再起動には、ResourceManager の再起動およびNodeManager の再起動が含まれます。ResourceManager はアプリケーションの基本情報とステータスを維持し、NodeManager は実行中のコンテナーの情報とステータスを維持します。これらのコンポーネントはどちらも、Apache ZooKeeper や LevelDB、Hadoop 分散ファイルシステム (HDFS) などの外部ストレージシステムに対して継続的に状態を同期します。

再起動後、状態は自動的に再読み込みされ、復元されます。アプリケーションおよびコンテナーは中断なく再開します。ほとんどの場合、クラスターのスペックアップや再起動は、実行中のアプリケーションおよびコンテナーに対して認識されません。

ResourceManager の高可用性 (HA) を有効にする方法

EMR コンソールの YARN サービスページの [構成] タブで、次のパラメーターを確認または設定します。

ResourceManager サービスが正常かどうかを確認する方法

網羅性が高まる順に、次の3つのメソッドがあります。

1. ResourceManager の高可用性 (HA) ステータスを確認します。 高可用性 (HA) クラスターでは、Active 状態の ResourceManager プロセスが正確に 1 つ存在している必要があります。haState が ACTIVE または STANDBY であり、かつ haZooKeeperConnectionState が CONNECTED であることを確認します。

• コマンドラインインターフェイス (CLI)：yarn rmadmin -getAllServiceState を実行します。

• RESTful API：http://<rmAddress>/ws/v1/cluster/info にアクセスします。

2. YARN アプリケーションのステータスを確認します。 yarn application -list を実行し、SUBMITTED または ACCEPTED 状態で停止しているアプリケーションがないか確認します。

3. テストアプリケーションを送信します。 新しいアプリケーションが実行および完了できることを確認します。

hadoop jar <hadoop_home>/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-*-tests.jar sleep -m 1 -mt 1000 -r 0

特定のキューに送信するには、sleep と -m の間に -Dmapreduce.job.queuename を追加します。デフォルトのキューは default です。

単一のタスクまたはコンテナーの最大リソースを制御するパラメーター

タスクまたはコンテナーごとの最大リソースは、クラスターレベルおよびキュー レベルのスケジューラー設定によって決まります。

リクエストが最大値を超える場合、アプリケーションログに InvalidResourceRequestException: Invalid resource request... という例外が表示されます。

YARN 構成の変更が反映されない場合の対処方法

構成ファイルの種類によって、必要な後続の操作が異なります。

コンポーネント再起動の例：

• yarn-env.sh の YARN_RESOURCEMANAGER_HEAPSIZE または yarn-site.xml の yarn.resourcemanager.nodes.exclude-path を変更した後は、ResourceManager を再起動します。

• yarn-env.sh の YARN_NODEMANAGER_HEAPSIZE または yarn-site.xml の yarn.nodemanager.log-dirs を変更した後は、NodeManager を再起動します。

• mapred-env.sh の MAPRED_HISTORYSERVER_OPTS または mapred-site.xml の mapreduce.jobhistory.http.policys を変更した後は、MRHistoryServer を再起動します。

ホットアップデートを構成する方法

手順 1：主要なパラメーターを設定します。

EMR コンソールの YARN サービスページの [構成] タブで、次の操作を行います。

手順 2：現在のスケジューラー構成を表示します。

• RESTful API： http://<rm-address>/ws/v1/cluster/scheduler-conf にアクセスします。

• HDFS： ${yarn.scheduler.configuration.fs.path}/capacity-scheduler.xml.<timestamp> を参照します。タイムスタンプが最も大きいファイルが最新の構成です。

手順 3：API を介して構成を更新します。

例：yarn.scheduler.capacity.maximum-am-resource-percent を変更し、yarn.scheduler.capacity.xxx を削除します（パラメーターを削除するには値フィールドを削除します）。

curl -X PUT -H "Content-type: application/json" 'http://<rm-address>/ws/v1/cluster/scheduler-conf' -d '
{
  "global-updates": [
    {
      "entry": [{
        "key":"yarn.scheduler.capacity.maximum-am-resource-percent",
        "value":"0.2"
      },{
        "key":"yarn.scheduler.capacity.xxx"
      }]
    }
  ]
}'

キュー内のアプリケーション間でリソース配分が不均等になる場合の対処方法

大規模なジョブがキュー内のすべてのリソースを消費し、小規模なジョブがリソース不足に陥ることがよくあります。これを修正するには、次の 2 つの変更を行います。

1. キューの順序付けポリシーを FIFO から公平に切り替えます。

yarn.scheduler.capacity.<queue-path>.ordering-policy をデフォルトの fifo から fair に変更します。

First In, First Out (FIFO) スケジューラーと公平スケジューラーは、YARN における 2 種類のスケジューラーです。

必要に応じて、yarn.scheduler.capacity.<queue-path>.ordering-policy.fair.enable-size-based-weight を設定します。デフォルトは false で、リソース使用量の昇順でジョブを並べ替えます。true に設定すると、リソース需要に対するリソース使用量の比率の昇順で並べ替えます。

2. キュー内リソースのプリエンプションを有効にします。

キュー間リソースのプリエンプションはデフォルトで有効になっており、無効化できません。キュー内プリエンプションも有効にするには、次のパラメーターを構成します。

キューのリソース使用量を確認する方法

YARN Web UI の [Used Capacity] メトリックを確認します。Used Capacity は、キューに割り当てられた全リソースに対する、そのキューで消費されたリソースの割合 (%) です。メモリリソースの割合と vCores の割合はそれぞれ別々に計算され、大きい方が Used Capacity の値になります。

表示するには：

1. YARN Web UI を開きます。詳細については、「オープンソースコンポーネントの Web UI へのアクセス」をご参照ください。

2. [すべてのアプリケーション] ページで、特定のジョブの ID をクリックします。

3. Queue 行で目的のキューをクリックします。

4. [Application Queues] セクションで、リソース使用量を確認します。

アプリケーションのステータスを取得する方法

アプリケーションの問題をトラブルシューティングする方法

以下の段階的なワークフローに従ってください。

手順 1：アプリケーションのステータスを確認します。

アプリケーション詳細ページまたは RESTful API (http://<rmAddress>/ws/v1/cluster/apps/<applicationId>) でステータスを確認します。ステータスに基づいて診断します。

Unknown ステータス：

アプリケーションが YARN への送信前に失敗したか、ResourceManager に到達できない状態です。

• BRS や FlowAgent などのクライアントコンポーネントのアプリケーション送信ログを確認し、問題がないかチェックします。

• ネットワーク接続が異常な場合、クライアント側で次のエラーが表示されます。

    com.aliyun.emr.flow.agent.common.exceptions.EmrFlowException: ###[E40001,RESOURCE_MANAGER]: Failed to access to resource manager, cause: The stream is closed

NEW_SAVING：

アプリケーション情報が ZooKeeper ステートストアに書き込まれています。ここで停止している場合は、ZooKeeper が正常かどうかを確認します。ZooKeeper の読み取り/書き込みエラーについては、「ResourceManager が Standby から Active に切り替わらない場合の対処方法」をご参照ください。

SUBMITTED：

通常の状態では稀です。大規模クラスターでは、Capacity Scheduler のロック競合によりこの状態になることがあります。最適化の詳細については、「YARN-9618」をご参照ください。

ACCEPTED — 診断メッセージを確認します：

RUNNING：

アプリケーションが実行中だが停止しているように見える場合は、手順 2 に進み、コンテナーリソースリクエストが保留されているかどうかを確認します。

FAILED — 診断メッセージを確認します：

手順 2：YARN リソース割り当てが保留されているかどうかを確認します。

1. アプリケーション一覧ページで、アプリケーション ID をクリックします。

2. アプリケーション詳細ページで、アプリケーション試行 ID をクリックします。

3. [Total Outstanding Resource Requests] リストで保留中のリソースを確認します。保留中のリソースは、保留リクエスト用の RESTful API でもクエリできます。

   • 保留中のリソースが存在しない場合、YARN リソース割り当ては完了しています。このワークフローを終了し、AM リソース割り当てを確認してください。

   • 保留中のリソースが存在する場合、手順 3 に進みます。

手順 3：リソース制限を確認します。

クラスターおよびキューのリソースを確認します。特に、[有効な最大リソース] および [使用済みリソース] の値を確認します。

1. クラスターリソース、キュー リソース、または親キュー リソースが完全に消費されているかどうかを確認します。

2. リーフ キュー内のリソース ディメンションのいずれかが上限に近づいているか、または達しているかを確認してください。

3. クラスターのリソース使用率が 100% に近い場合 (例：85% を超える場合)、アプリケーションへのリソース割り当て速度が低下することがあります。主な原因は次の 2 つです。

   • マシンのほとんどに利用可能なリソースがなく、リザーブが発生しています。十分なマシンがリザーブされると、割り当て速度が低下します。

   • マシン間でメモリと CPU リソースのバランスが取れていません。一部のマシンにはアイドルメモリがあるもののアイドル CPU がなく、逆のケースもあります。

手順 4：割り当てられたコンテナーが起動に失敗していないかを確認します。

YARN Web UI の App Attempt ページで、割り当てられたコンテナー数と短時間での変化を観察します。コンテナーの起動に失敗した場合は、NodeManager ログまたはコンテナーログからトラブルシューティングを行います。

手順 5：より詳細な調査のためにデバッグレベルのロギングを有効にします。

YARN Web UI のログレベルページ (http://RM_IP:8088/logLevel) で、org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity のログレベルを DEBUG に変更します。

ResourceManager が Standby から Active に切り替わらない場合の対処方法

まず、高可用性 (HA) パラメーターを確認します。 次の 3 つのパラメーターはすべて true である必要があります。

上記が正しい場合、ZooKeeper を調査します。

• ZooKeeper が正常かどうかを確認します。

• ZooKeeper クライアントバッファーオーバーフロー。 ResourceManager ログに Zookeeper error len*** is out of range! または Unreasonable length = *** が含まれている場合、次の操作を行います。EMR コンソールの YARN サービスページの [構成] タブで、[yarn-env] タブをクリックし、yarn_resourcemanager_opts に -Djute.maxbuffer=4194304 を設定します。その後、ResourceManager を再起動します。

• ZooKeeper サーバーバッファーオーバーフロー。 ZooKeeper ログに Exception causing close of session 0x1000004d5701b6a: Len error *** が含まれている場合、各 ZooKeeper ノードの -Djute.maxbuffer= パラメーターを追加または更新して、バッファー制限 (単位：バイト) を増やします。

• ZooKeeper のエフェメラルノードが停止している。 ResourceManager および ZooKeeper のログに例外が表示されていない場合、リーダー選出のエフェメラルノードが古いセッションによって占有されていないかを確認します。${yarn.resourcemanager.zk-state-store.parent-path}/${yarn.resourcemanager.cluster-id}/ActiveStandbyElectorLock のノードで ZooKeeper CLI の stat コマンドを実行します。修正方法：Curator ベースのリーダー選出に切り替えます。[yarn-site] タブで、yarn.resourcemanager.ha.curator-leader-elector.enabled を true に追加または設定します。その後、ResourceManager を再起動します。

ResourceManager でメモリ不足 (OOM) が発生した場合の対処方法

ResourceManager ログから OOM のタイプを特定します。

エラー：Java heap space、GC overhead limit exceeded、または繰り返し発生するフル GC

Java 仮想マシン (JVM) のヒープメモリが枯渇しています。ResourceManager はメモリ内にクラスター、キュー、アプリケーション、コンテナー、ノードなどの多くの常駐オブジェクトを保持します。これらのオブジェクトが消費するヒープメモリはクラスター規模に比例して増加します。また、既存データも時間とともに蓄積されます。シングルノードクラスターであっても、既存データのためのメモリを消費します。ResourceManager の最小推奨ヒープメモリ：2 GB。

修正：

• yarn-env.sh の YARN_RESOURCEMANAGER_HEAPSIZE を変更して、ヒープメモリを増やします。

• yarn-site.xml の yarn.resourcemanager.max-completed-applications を変更して、保存される既存アプリケーション数を減らします (デフォルト：10000)。

エラー：unable to create new native thread

ResourceManager が実行されているノードが、システムスレッド制限に達しています。最大スレッド数は、ユーザーごとの制限とシステムプロセス識別子 (PID) 制限によって決まります。

制限を確認します。

ulimit -a | grep "max user processes"
cat /proc/sys/kernel/pid_max

スレッド数の多い上位 10 プロセスを検索します。

ps -eLf | awk '{print $2}' | uniq -c | awk '{print $2"\t"$1}' | sort -nrk2 | head

出力は [プロセス ID] [スレッド数] の形式で表示されます。

修正:

• スレッドまたは PID 制限が低すぎる場合は、システム設定で増やします。小規模スペックのノードでは通常数万、大規模スペックのノードでは数十万が必要です。

• 制限が妥当な場合は、最も多くのスレッドを消費しているプロセスを調査します。

RPC バージョン不一致エラーが表示された場合の対処方法

Exception while invoking getClusterNodes...Trying to fail over immediately というエラーメッセージは、アクティブな ResourceManager にアクセスできないことを示しています。ResourceManager ログには次のような内容が含まれます。

WARN org.apache.hadoop.ipc.Server: Incorrect header or version mismatch from 10.33.**.**:53144 got version 6 expected version 9

Hadoop の古いバージョンが使用されています。アプリケーションクライアントが使用するリモートプロシージャコール (RPC) バージョンが、クラスター上の Hadoop バージョンと互換性がありません。

修正方法：アプリケーションクライアントの RPC バージョンと互換性のある Hadoop バージョンを使用します。

ノードがジョブを開始する際にローカライズが失敗し、ジョブログが収集または削除できない理由

NodeManager ログに次のような内容が含まれます。

java.io.IOException: Couldn't create proxy provider class org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider

HDFS 構成が正しくありません。この例外はラッパーであり、根本原因ではありません。実際の問題を特定するために、デバッグレベルのロギングを有効にしてください。

• Hadoop クライアント CLI で hadoop fs -ls / などのコマンドを実行した後、デバッグを有効にします。

    export HADOOP_LOGLEVEL=DEBUG

• Log4j を使用するランタイム環境では、Log4j 構成に次の行を追加します。

    log4j.logger.org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider=DEBUG

一般的な根本原因：NameServices 構成が変更された場合 (例：emr-cluster から hadoop-emr-cluster に変更)、スケールアウトで追加された新しいノードが元の NameServices 構成を使用し続けていることです。

修正方法：EMR コンソールの HDFS サービスページの [構成] タブで、パラメーターが正しく構成されていることを確認します。

リソースローカライズ例外を処理する方法

症状：

• AM コンテナーが次の診断メッセージで起動に失敗します。

    Application application_1412960082388_788293 failed 2 times due to AM Container for appattempt_1412960082388_788293_000002 exited with exitCode: -1000 due to: EPERM: Operation not permitted

• NodeManager ログに、ダウンロードされたリソースパッケージの解凍中にエラーが表示されます。

    INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.localizer.ResourceLocalizationService: Failed to download rsrc { { hdfs://hadoopnnvip.cm6:9000/user/heyuan.lhy/apv/small_apv_20141128.tar.gz, 1417144849604, ARCHIVE, null },pending,[(container_1412960082388_788293_01_000001)],14170282104675332,DOWNLOADING}
    EPERM: Operation not permitted
            at org.apache.hadoop.io.nativeio.NativeIO$POSIX.chmodImpl(Native Method)
            at org.apache.hadoop.io.nativeio.NativeIO$POSIX.chmod(NativeIO.java:226)
            at org.apache.hadoop.fs.RawLocalFileSystem.setPermission(RawLocalFileSystem.java:629)
            ...

アプリケーションリソースパッケージにシンボリックリンクが含まれており、chmod 操作が失敗しています。

修正方法：アプリケーションリソースパッケージからシンボリックリンクを削除します。

「No space left on device」というエラーが表示され、コンテナーの起動または実行に失敗した場合の対処方法

次の原因を順に確認します。

1. ディスク領域。 ディスクに空き領域があることを確認します。

2. cgroups cgroup.clone_children 設定。 /sys/fs/cgroup/cpu/hadoop-yarn/ および /sys/fs/cgroup/cpu/ の値を確認します。

   • cgroup.clone_children が 0 の場合、1 に変更します：bash echo 1 > /sys/fs/cgroup/cpu/cgroup.clone_children

   • 問題が解決しない場合、同じディレクトリレベルにある cpuset.mems または cpuset.cpus ファイルを確認します。hadoop-yarn ディレクトリの値が、上位ディレクトリの値と一致している必要があります。

3. cgroups サブディレクトリ制限。 cgroups ディレクトリ下のサブディレクトリ数が上限の 65,535 を超えていないかを確認します。確認方法：YARN 構成ファイルを見つけ、yarn.nodemanager.linux-container-executor.cgroups.delete-delay-ms または yarn.nodemanager.linux-container-executor.cgroups.delete-timeout-ms パラメーターを確認します。

NodeManager またはジョブ実行中にドメイン名が解決できない場合の対処方法

エラーメッセージ：

java.net.UnknownHostException: Invalid host name: local host is: (unknown)

次の原因を順に確認します。

1. DNS 構成。 DNS サーバーが正しく構成されていることを確認します。

      cat /etc/resolv.conf

2. ファイアウォールルール。 ポート 53 に対して必要なルールが構成されているかを確認します。ルールが構成されている場合は、ファイアウォールを無効にしてください。

3. NSCD サービス。 Name Service Cache Daemon (NSCD) サービスが実行されているかを確認します。NSCD が実行中の場合、停止します。

      systemctl status nscd

      systemctl stop nscd

NodeManager でメモリ不足 (OOM) が発生した場合の対処方法

NodeManager ログから OOM のタイプを特定します。

エラー：Java heap space、GC overhead limit exceeded、または繰り返し発生するフル GC

NodeManager は常駐オブジェクトが少ない (現在のノード、アプリケーション、コンテナーのみ) ですが、外部シャッフルサービスのキャッシュおよびバッファーが大量のヒープメモリを消費することがあります。関連するパラメーターは次のとおりです。

• Spark：spark.shuffle.service.index.cache.size、spark.shuffle.file.buffer

• MapReduce：mapreduce.shuffle.ssl.file.buffer.size、mapreduce.shuffle.transfer.buffer.size

シャッフルサービスが消費するヒープメモリは、それを利用するアプリケーションおよびコンテナーの数に比例します。タスクが多い大規模ノードでは、より多くのメモリが必要です。NodeManager の最小推奨ヒープメモリ：1 GB。

修正：

• yarn-env.sh の YARN_NODEMANAGER_HEAPSIZE を変更して、ヒープメモリを増やします。

• シャッフルサービスのキャッシュ設定が妥当かどうかを確認します。たとえば、Spark シャッフルキャッシュがヒープの大部分を消費していないことを確認します。

エラー：Direct buffer memory

ヒープ外メモリがオーバーフローしています。これは通常、RPC に NIO DirectByteBuffer を使用する外部シャッフルサービスによって引き起こされます。

ヒープ外メモリの消費量は、シャッフルサービスを利用するアプリケーションおよびコンテナーの数に比例します。シャッフル集約型のタスクを多数実行するノードでは、ヒープ外メモリの割り当てが小さすぎる可能性があります。

修正方法：yarn-env.sh の YARN_NODEMANAGER_OPTS に設定されている XX:MaxDirectMemorySize の値を確認します。設定されていない場合、ヒープ外メモリサイズはヒープメモリサイズと同じになります。値が小さすぎる場合は増やしてください。

エラー：unable to create new native thread

根本原因と解決方法は、ResourceManager の OOM スレッド問題と同じです。「ResourceManager でメモリ不足 (OOM) が発生した場合の対処方法」をご参照ください。

ECS インスタンスの再起動後、cgroups ディレクトリが見つからないため NodeManager が起動に失敗する場合の対処方法

エラーメッセージ：

ResourceHandlerException: Unexpected: Cannot create yarn cgroup Subsystem:cpu Mount point:/proc/mounts User:hadoop Path:/sys/fs/cgroup/cpu/hadoop-yarn

ECS インスタンスが異常終了後に再起動した可能性があります。これはカーネルの欠陥によるもので、カーネルバージョン 4.19.91-21.2.al7.x86_64 で既知の問題です。再起動後、メモリ内の cgroups データが削除され、cgroups が無効になります。

修正方法：ノードグループにブートストラップスクリプトを追加し、起動時に cgroups ディレクトリを作成し、rc.local を通じて永続化します。

# enable cgroups
mkdir -p /sys/fs/cgroup/cpu/hadoop-yarn
chown -R hadoop:hadoop /sys/fs/cgroup/cpu/hadoop-yarn
# enable cgroups after reboot
echo "mkdir -p /sys/fs/cgroup/cpu/hadoop-yarn" >> /etc/rc.d/rc.local
echo "chown -R hadoop:hadoop /sys/fs/cgroup/cpu/hadoop-yarn" >> /etc/rc.d/rc.local
chmod +x /etc/rc.d/rc.local

NodeManager のリソース構成を保存して再起動しても反映されない場合の対処方法

yarn.nodemanager.resource.cpu-vcores および yarn.nodemanager.resource.memory-mb パラメーターを変更して保存しましたが、NodeManager を再起動しても変更が反映されません。

ノードグループ内のインスタンスでは CPU コア数およびメモリサイズが異なる場合があります。これらのパラメーターはクラスターレベルではなく、ノードグループレベルで設定する必要があります。

修正方法：EMR コンソールで、YARN サービスページの [構成] タブに移動します。検索ボックス横のドロップダウンリストから [ノードグループ構成] を選択します。NodeManager が属するノードグループを選択します。その後、yarn.nodemanager.resource.cpu-vcores および yarn.nodemanager.resource.memory-mb を変更します。詳細については、「設定項目の管理」をご参照ください。

ノードが非健全としてマークされた場合の対処方法

考えられる原因は次の 2 つです。

1. ディスクヘルスチェックの失敗。 ノード上の健全なディレクトリの比率が yarn.nodemanager.disk-health-checker.min-healthy-disks (デフォルト：0.25) を下回ると、ノードは非健全としてマークされます。4 台のディスクを持つノードの場合、4 台すべてのディスクに異常なディレクトリが存在しない限り、ノードは非健全としてマークされません。そうでない場合は、「local-dirs are bad」または「log-dirs are bad」というレポートのみが表示されます。「「local-dirs are bad」または「log-dirs are bad」と表示された場合の対処方法」をご参照ください。

2. NodeManager ヘルスチェックスクリプト。 デフォルトではスクリプトは無効になっています。yarn-site.xml で yarn.nodemanager.health-checker.script.path を構成することで有効にします。このスクリプトが問題を検出した場合は、カスタムスクリプトのロジックに基づいて問題を解決します。

「local-dirs are bad」または「log-dirs are bad」と表示された場合の対処方法

ディスクヘルスチェック (デフォルトで有効) は定期的に、local-dirs (ファイルおよび中間データ用のタスクキャッシュディレクトリ) および log-dirs (タスクログディレクトリ) が次の条件を満たしているかどうかを確認します。

• 読み取り可能

• 書き込み可能

• 実行可能

• ディスク使用率が yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage (デフォルト：90%) を下回っている

• 残りの利用可能ディスク領域が yarn.nodemanager.disk-health-checker.min-free-space-per-disk-mb (デフォルト：0) を上回っている

いずれかの条件を満たしていない場合、ディレクトリは不良とマークされます。

修正：

• ディスク領域不足 (最も一般的)。次のいずれかに該当する場合、ディスクをスケールアウトします：ノードのスペックが高くタスクが多い、ディスク領域が小さい、タスクデータまたは中間データが大きい、タスクログが大きい。

• キャッシュが大きすぎる。 yarn-site.xml の yarn.nodemanager.localizer.cache.target-size-mb を確認します。キャッシュとディスクの比率が高すぎると、しきい値を超えた場合にのみキャッシュがクリーンされるため、キャッシュされたタスクデータがディスクの大部分を占めてしまいます。

• ディスクの損傷。 「EMR クラスターの損傷したローカルディスクの交換」をご参照ください。

YARN サービスコンポーネントの .out ログファイルが大量に蓄積する理由

特定の Hadoop 依存ライブラリは Log4j ではなく Java ロギング API を呼び出すため、ログローテーションをサポートしていません。デーモンコンポーネントの標準エラー (stderr) 出力は .out ログファイルにリダイレクトされます。自動クリーンアップメカニズムがないため、これらのログが蓄積し、データディスクを満杯にすることがあります。

修正方法：head および tail コマンドを使用して、ログ内のタイムスタンプ情報を基に、最も多くの領域を消費している Java ロギング API ログを特定します。ほとんどの場合、これらはコンポーネント機能に影響を与えない依存ライブラリの INFO レベルのログです。問題のあるパッケージの INFO レベルのログ生成を無効にします。

例：Timeline Server の Jersey ログ生成を無効にする。

1. YARN ログディレクトリの timelineserver- で始まる .out ログファイルを監視します。出力には com.sun.jersey パッケージによって生成されたレコードが含まれます。

   • DataLake クラスターパス：/var/log/emr/yarn/

   • Hadoop クラスターパス：/mnt/disk1/log/hadoop-yarn

      tail /var/log/emr/yarn/*-hadoop-timelineserver-*.out

2. Timeline Server ノードで、root として Jersey ロギングを無効にする構成ファイルを作成します。

      sudo su root -c "echo 'com.sun.jersey.level = OFF' > $HADOOP_CONF_DIR/off-logging.properties"

3. EMR コンソールの YARN サービスページの [構成] タブで、YARN_TIMELINESERVER_OPTS (または Hadoop クラスターの場合は yarn_timelineserver_opts) を検索します。値に次の内容を追加します。

      -Djava.util.logging.config.file=off-logging.properties

4. 構成を保存し、Timeline Server を再起動します。Timeline Server が正常に起動し、.out ログファイルに com.sun.jersey のエントリが表示されなくなった場合、修正は成功しています。

「User [dr.who] is not authorized to view the logs for application」というエラーが表示された場合の対処方法

NodeManager ログページにアクセスする際に、アクセス制御リスト (ACL) ルールがチェックされます。ACL ルールが有効になっている場合、リモートユーザーがアプリケーションログを表示するには、次のいずれかの条件を満たす必要があります。

• リモートユーザーが管理者ユーザーであること。

• リモートユーザーがアプリケーションのオーナーであること。

• リモートユーザーがアプリケーション用にカスタマイズされた ACL ルールを満たすこと。

修正方法：リモートユーザーが上記のいずれかの条件を満たしていることを確認します。

「HTTP ERROR 401 Authentication required」または「HTTP ERROR 403 Unauthenticated users are not authorized to access this page」と表示された場合の対処方法

YARN はシンプル認証を使用しており、デフォルトでは匿名アクセスを許可していません。「Hadoop HTTP Web コンソールの認証」をご参照ください。

修正点:

• 方法 1： URL パラメーターに user.name=*** を追加して、リモートユーザーを指定します。

• 方法 2： EMR コンソールの HDFS サービスページの [構成] タブの [構成フィルター] セクションで、hadoop.http.authentication.simple.anonymous.allowed を検索し、true に設定して匿名アクセスを許可します。その後、HDFS サービスを再起動します。詳細については、「サービスの再起動」をご参照ください。

TotalVcore の表示値が正しくない理由

YARN Web UI (右上隅) のクラスターまたはメトリクス RESTful API セクションで、TotalVcore 値が誤っている場合があります。これは Apache Hadoop 2.9.2 より前のバージョンの計算ロジックのバグです。「YARN-8443」をご参照ください。

この問題は EMR V3.37.x、EMR V5.3.x およびそれ以降のマイナーバージョンで修正されています。

Tez Web UI のアプリケーション情報が不完全な場合の対処方法

ブラウザの [開発者ツール] を開き、どのリクエストが失敗しているかを確認します。

1. http://<rmAddress>/ws/v1/cluster/apps/APPID へのリクエストが失敗。 ResourceManager がアプリケーションデータをクリアしています。デフォルトでは、ResourceManager は最大 1,000 件のアプリケーション情報を保持します。この制限を超えたアプリケーションは、開始順にクリアされます。

2. http://<tsAddress>/ws/v1/applicationhistory/... へのリクエストがエラーコード 500 (アプリケーションが見つかりません) を返す。 アプリケーション情報が保存に失敗したか、Timeline ストアによってクリアされました。

   • yarn.resourcemanager.system-metrics-publisher.enabled を確認して、保存の失敗を判断します。

   • LevelDB の存続時間 (TTL) を確認して、データがクリアされたかどうかを判断します。

3. http://<tsAddress>/ws/v1/timeline/... へのリクエストがコード 200 を返すが、NotFound と表示される。 AM syslog の初期化出力を確認します。正常な初期化は次のようになります。次の警告が表示される場合、実行中の AM の yarn.timeline-service.enabled が false に設定されています。考えられる原因は FlowAgent の問題です。FlowAgent を介して実装された Hive ジョブ (Hive コマンドまたは Beeline コマンドを使用) では、FlowAgent のデフォルトで yarn.timeline-service.enabled が false に設定されています。

      [INFO] [main] |history.HistoryEventHandler|: Initializing HistoryEventHandler withrecoveryEnabled=true, historyServiceClassName=org.apache.tez.dag.history.logging.ats.ATSHistoryLoggingService
      [INFO] [main] |ats.ATSHistoryLoggingService|: Initializing ATSHistoryLoggingService with maxEventsPerBatch=5, maxPollingTime(ms)=10, waitTimeForShutdown(ms)=-1, TimelineACLManagerClass=org.apache.tez.dag.history.ats.acls.ATSHistoryACLPolicyManager

      [WARN] [main] |ats.ATSHistoryLoggingService|: org.apache.tez.dag.history.logging.ats.ATSHistoryLoggingService is disabled due to Timeline Service being disabled, yarn.timeline-service.enabled set to false

YARN Web UI で Spark Thrift JDBC/ODBC Server タスクが実行されている理由

クラスター作成時に Spark を選択した場合、デフォルトの Spark Thrift Server サービスが自動的に起動します。このサービスは 1 つの YARN ドライバーリソースを占有します。デフォルトでは、Spark Thrift Server で実行されるタスクは、このドライバーを通じて YARN からリソースをリクエストします。

yarn.timeline-service.leveldb-timeline-store.path パラメーターを OSS バケット URL に設定できるか

いいえ。yarn.timeline-service.leveldb-timeline-store.path パラメーターを Object Storage Service (OSS) バケット URL に設定することはできません。

Hadoop クラスターでは、yarn.timeline-service.leveldb-timeline-store.path のデフォルト値は hadoop.tmp.dir の値と等しくなります。hadoop.tmp.dir は変更しないでください。変更すると、yarn.timeline-service.leveldb-timeline-store.path にも影響します。

Timeline Server への接続がタイムアウトする、または CPU 負荷またはメモリ使用量が極端に高い場合の対処方法

多数の Apache Tez ジョブがある場合、Timeline Server へのデータ書き込みがタイムアウトすることがあります。これは、Timeline Server プロセスが過剰な CPU リソースを消費し、そのノードの CPU 負荷が上限に達するためです。これにより、ジョブ開発やレポート生成などの非コアサービスに影響が出る可能性があります。

緊急対応として、Timeline Server プロセスを停止してノードの CPU 負荷を軽減します。その後、次の構成変更を適用します。

手順 1：Tez イベントフラッシュタイムアウトを設定します。

EMR コンソールの Tez サービスページの [構成] タブで、[tez-site.xml] タブに移動し、構成項目を追加します。

• 名前：tez.yarn.ats.event.flush.timeout.millis

• 値：60000

これにより、Tez ジョブが Timeline Server にイベントを書き込む際のタイムアウトが設定されます。

手順 2：Timeline Server ストレージを最適化します。

EMR コンソールの YARN サービスページの [設定] タブの [yarn-site.xml] タブで、これらの設定項目を追加または変更します：

これらの変更を加えた後、YARN サービスページの [ステータス] タブで Timeline Server を再起動します。構成の管理に関する詳細については、「設定項目の管理」をご参照ください。