YARNでSparkアプリケーションの物理メモリ使用量が増え続けている

Question

SparkアプリケーションをYARNクライアントモードで6つのエグゼキュータ（4つのコアと実行メモリ= 6 GB、オーバーヘッド= 4 GB、スパークバージョン：1.6.3/2.1.0）。

私の実行プログラムのメモリは、ノードマネージャによって強制終了されるまで増加し続けます。 spark.yarn.excutor.memoryOverheadを増やすように指示する情報を提供します。

このパラメータは、主にオフヒープに割り当てられたメモリのサイズを制御することがわかります。しかし、Sparkエンジンがこの部分のメモリをいつ、どのように使うのかはわかりません。また、その部分を増やしても必ずしも私の問題が解決されるわけではありません。時にはうまくいくこともあります。入力データが大きいときは、無駄になる傾向があります。

参考までに、私のアプリケーションのロジックは非常に単純です。これは、1日に生成された小さなファイル（1つのディレクトリを1日分）を1つにまとめ、HDFSに書き戻すことを意味します。ここにコアコードがあります：

val df = spark.read.parquet(originpath) 
       .filter(s"m = ${ts.month} AND d = ${ts.day}") 
       .coalesce(400) 
val dropDF = df.drop("hh").drop("mm").drop("mode").drop("y").drop("m").drop("d") 

dropDF.repartition(1).write 
     .mode(SaveMode.ErrorIfExists) 
     .parquet(targetpath) 

ソースファイルには、数百から数千のレベルのパーティションがあります。そして寄木細工の総ファイル数は約1から5   GBです。

また、別のマシンからデータをシャッフルするステップでは、シャッフル読み取りのサイズが入力サイズの約4倍であることがわかりました。

とにかく、私はこの問題を自分でいくつか検索しました。いくつかの記事は、それが直接バッファメモリ上にあると言っています（私は自分自身を設定しません）。

一部の記事では、より多くの完全GCを使用して解決するとの記事があります。

はまた、私は非常に似たような状況でスタックオーバーフロー に1人を見つける：Ever increasing physical memory for a Spark application in YARN

この男は、寄木細工のバグだと主張したが、コメントは彼に疑問を呈しました。このメールリストの人々はまた、JSONを書きながら、この問題を説明blondowskiから前に電子メールの時間を受け取ることがあります。Executors - running out of memory

だから、さまざまな出力形式のための共通の問題であることをように見えます。

この問題についての経験をお持ちの方は、この問題について説明していただければ幸いです。なぜこれが起こり、この問題を解決する信頼できる方法は何ですか？

Answer 1

最近私の同僚と調査しています。これは私の考えです：スパーク1.2から、私たちはシャッフルとキャッシュブロック転送中にGCを減らすためにオフヒープメモリを持つNettyを使います。私の場合、もし私が十分な大きさのメモリオーバーヘッドを増やそうとすれば。私は最大直接バッファ例外を取得します。 Nettyが転送をブロックすると、データチャンクをターゲットエクゼキュータに取り込むためにデフォルトで5つのスレッドが存在します。私の状況では、1つのチャンクが大きすぎてバッファに収まらない。だからGcはここで助けません。私の最終的な解決策は、再分割の前に別の再分割を行うことです（1）。オリジナルのものよりも10倍以上のパーティションを作るだけです。このようにして、各チャンクNetty転送のサイズを減らすことができます。こうして私はついにそれを作ります。

また、大きなデータセットを1つのファイルに再分割するのは良い選択ではないと言いたいと思います。この非常に不均衡なシナリオは、コンピューティングリソースを浪費するものです。

ご意見がありましたら、この部分はよく分かりません。