2016-07-29 4 views
1

何らかの理由により、何らかの理由でクラスタが誤動作しているように見えます。突然YARNジョブの数が急増しています.HDInsight LinuxベースのHadoopクラスタを使用しています。 Azure Data Factoryジョブを実行して、基本的にこのクラスタを指すハイブスクリプトを実行します。特定の時点でのYARNアプリの平均的な数は、実行中は50、保留中は40〜50です。 Noneは、このクラスタをアドホッククエリの実行に使用します。しかし、数日後には何か変わったことに気がつきました。突然、紡績アプリの数が増え始めます。実行中でも保留中ですが、特に保留中のアプリです。したがって、この数は、紡績アプリを実行する場合は100を超え、保留の場合は400以上、場合によっては500以上になります。私たちには、すべての糸アプリを1つずつ殺すスクリプトがありますが、それは長い時間がかかりますが、それは実際の解決策ではありません。私たちの経験から、唯一の解決策は、クラスタが削除され、再作成されることです。スライスが失敗した場合にADFが何度も再試行を続けても、クラスタがすべての失敗したスライス実行要求を格納している可能性があります。 (ADFによると)プールで実行可能なときに実行しようとしていますか?おそらくそれが起こる可能性があるのは唯一の説明でしょう。誰もこの問題に直面していますか?HDInsightクラスタのYARNアプリケーションの数が突然急増しました

答えて

1

デフォルトキューの実行中のジョブがすべてTempletonジョブであるかどうかを確認します。もしそうなら、あなたのキューはデッドロックされています。

AzureデータファクトリはWebHCat(Templeton)を使用してHDInsightにジョブを送信します。 WebHCatは親Templetonジョブをスピンアップし、実行しようとしている実際のHiveスクリプトである子ジョブを送信します。子ジョブ(実際の作業)がアプリケーションマスターをスピンアップできないため、一度に親ジョブが多すぎると、スレッドキューがデッドロックになる可能性があります。したがって、実際に作業は行われません。 Templetonのジョブを終了すると、明らかにそうではないにもかかわらず、データ・ファクトリでタイム・スライスが完了したとマークされます。

デッドロック状態になっている場合は、最大AMリソースをデフォルトの33%からもっと高いレベルに調整したり、クラスタを拡大したりすることができます。目標は、保留中の子ジョブの一部を実行し、キューをゆっくり排出させることです。

正しい長期的な修正として、親のtempletonジョブが別の糸待ち行列に送信されるようにWebHCatを構成する必要があります。これを行うには、(1)別々の糸待ち行列を作成し、(2)新しく作成されたキューにytonton.hadoop.queue.nameを設定します。

キューを作成するには、Ambari>糸キューマネージャを使用します。

Ambabを介してWebHCat設定を更新するには、[ハイブ]タブ> [詳細設定]> [高度なWebHCatサイト]に移動し、ここで設定値を更新します。

ウェブハード設定の詳細: https://cwiki.apache.org/confluence/display/Hive/WebHCat+Configure