2017-12-07 3 views
0

私はkafkaトピックから読み込み、寄木張りの形式でhdfsにデータを書き込むスパークストリーミングアプリケーションを持っています。 時間(非常に短い時間)の間、コンテナの物理メモリは最大サイズに達し、物理メモリの限界を超えて "Diagnostics:Container [pid = 29328、containerID = container_e42_1512395822750_0026_02_000001]が実行されていません。使い方:使用される1.5 GBの物理メモリの1.5 GB、使用される3.1 GBの仮想メモリの2.3 GB。 殺されているコンテナはドライバを実行するコンテナと同じで、アプリケーションも殺されます。 このエラーを探すときは、メモリを増やすという解決策しか見ていませんでしたが、これは問題を延期することになると思います。 メモリに何も保存しないと、なぜメモリが増加し続けるのか理解したい。 また、すべてのコンテナのメモリが増加していますが、しばらくしてから(最大に達する前に)殺されているだけです。 私はいくつかのポストで "あなたの仕事は寄木細工のデータを書き出しており、寄木張りのデータをディスクに書き出す前にメモリにバッファリングしています"と見ました。寄木細工へのスパークジョブの書き込み - 物理メモリが増え続けるコンテナを持っています

我々は(我々はまた、再分割せずに試してみました - それが必要とされているかわからない)を使用しているコード:

val repartition = rdd.repartition(6) 
val df: DataFrame = sqlContext.read.json(repartition) 
df.write.mode(SaveMode.Append).parquet(dbLocation) 

だけ増加メモリの問題を解決するためにいくつかの方法はありますか?

作成された寄木細工のファイル The created parquet files

メモリアプリケーションがちょうど書き込み以外何もしないと仮定すると、 enter image description here enter image description here enter image description here enter image description here enter image description here enter image description here

答えて

0

の増加を示し、ノードマネージャのログ、根本的な原因がサイズであると思われますバッチで受信されるデータの数。バッチの1つで受信したデータが、設定されたしきい値を超えている可能性があります。アプリケーションが今シーズンに殺されたとすると、解決策は「背圧」を有効にすることです。 解決策は、以下の記事で詳しく説明しています。

Limit Kafka batches size when using Spark Streaming

+0

メモリはただ時間の経過とともに上昇に保ち、1時間に増加されていないので、データが実際にキャッシュされているが、ガベージコレクタによって削除されないように思えます。少なくとも9時間後にアプリケーションが終了する – LubaT

+0

データパイプラインで、共用体のような変換やキーによる更新を使用していますか? – nkasturi

+0

いいえ、私が追加したコードはすべて私たちが行っています – LubaT

関連する問題