Flink Memory StateによるOOMの問題と解決
2220 ワード
一、現象
1.1プログラム現象
プログラムは,1つの業務を処理して2つのテーブル,4つのデータ,互いにJoinして2つの結果を形成する.FlinkはKafkaを読み込みます.アナログデータプログラムはKafkaにデータを挿入し続け、TaskManagerがメモリが低い場合、2000回の挿入(8000データの場合)をシミュレートすると、FlinkのTaskManagerでOOM問題が発生します.jstat-gcutilを使用する(小さな問題が発生したrootユーザーはyarnユーザーのjvm jstat情報を表示できずsocketファイルが見つかりません.
JVMプロセスを見ると、Old領域は若い世代のゴミ回収時に毎回5%程度の増加を続け、100%の状態に達することが分かった.FGCをしてもOldのメモリは落ちません.FGCが応答しないまま継続すると、JobManagerはそのcontainerのTaskManagerが応答していないと判断し、このTaskManagerを削除します.アプリケーション全体のTaskManagerが削除されるまで.最後のプログラムFinished(異常終了クラッシュ).
二、解決
2.1メモリの追加
最初の位置付けはメモリが足りないので、最初からTaskManagerにメモリを追加したいと思っていました.16 Gメモリに追加するまで.しかしOOMの問題は少しも改善されていない.24個のデータを処理した後.Old領域が切れて下がります.FGCを続けます.異常終了.
2.2 Dumpファイルの分析
16 GメモリTaskManagerの場合.dumpアウトOld領域が約90%の場合のスタックファイル(11 G).dumpファイルを8 Gのwindowsマシンにコピーし、MATツールを使って分析したが、分析に失敗した.Windowsの機械が足りない.
解決:linuxマシンでMat Linux版を使用します.コマンドラインツールを使用して分析します.(参考:https://blog.csdn.net/lxhandlbb/article/details/76695607 linuxはMATを使用してdumpファイルを分析するhttp://www.moheqionglin.com/site/blogs/84/detail.html )
その結果、以下の3つのzipファイルが生産され、本機jmap_に直接コピーすることができます.Leak_Suspects.zip jmap_System_Overview.zip jmap_Top_Components.zip分析結果zipファイルをローカルオープンブラウザにエクスポートして観察します.
CopyOnWriteStateTableが5.3 Gのメモリ領域を占めていることが明らかになった.Old領域で生き残る.ゴミ回収できません.このCopyOnWriteStateTableはFlinkのMemory Stateです.生産使用は推奨されません.
2.6 RocksDBの導入
そこでプログラムにrocksdb(RocksDB紹介:https://www.jianshu.com/p/73fa1d4e4273 、 https://www.ververica.com/blog/stateful-stream-processing-apache-flink-state-backends、 https://blog.csdn.net/zhangjun5965/article/details/88885534)、コードを変更してrocksDBを使用し、パスを設定します.
再パッケージングプログラムの実行後.13分以内にkafkaに160万件のデータを挿入し続けた.
old領域はほとんど成長しない.成長も0.01%の速度で均一に増加した.OOMの問題を解決します.Flinkプログラムは正常に動作しています.
1.1プログラム現象
プログラムは,1つの業務を処理して2つのテーブル,4つのデータ,互いにJoinして2つの結果を形成する.FlinkはKafkaを読み込みます.アナログデータプログラムはKafkaにデータを挿入し続け、TaskManagerがメモリが低い場合、2000回の挿入(8000データの場合)をシミュレートすると、FlinkのTaskManagerでOOM問題が発生します.jstat-gcutilを使用する(小さな問題が発生したrootユーザーはyarnユーザーのjvm jstat情報を表示できずsocketファイルが見つかりません.
Unable to open socket file: target process not responding or HotSpot VM not loadedは過去を切り替える必要があります.yarnユーザーを切り替えるにはリソースが足りません.linux構成を変更する必要があります.https://www.cnblogs.com/taiguyiba/p/7868894.html) JVMプロセスを見ると、Old領域は若い世代のゴミ回収時に毎回5%程度の増加を続け、100%の状態に達することが分かった.FGCをしてもOldのメモリは落ちません.FGCが応答しないまま継続すると、JobManagerはそのcontainerのTaskManagerが応答していないと判断し、このTaskManagerを削除します.アプリケーション全体のTaskManagerが削除されるまで.最後のプログラムFinished(異常終了クラッシュ).
二、解決
2.1メモリの追加
最初の位置付けはメモリが足りないので、最初からTaskManagerにメモリを追加したいと思っていました.16 Gメモリに追加するまで.しかしOOMの問題は少しも改善されていない.24個のデータを処理した後.Old領域が切れて下がります.FGCを続けます.異常終了.
2.2 Dumpファイルの分析
16 GメモリTaskManagerの場合.dumpアウトOld領域が約90%の場合のスタックファイル(11 G).dumpファイルを8 Gのwindowsマシンにコピーし、MATツールを使って分析したが、分析に失敗した.Windowsの機械が足りない.
解決:linuxマシンでMat Linux版を使用します.コマンドラインツールを使用して分析します.(参考:https://blog.csdn.net/lxhandlbb/article/details/76695607 linuxはMATを使用してdumpファイルを分析するhttp://www.moheqionglin.com/site/blogs/84/detail.html )
./ParseHeapDump.sh 12303.hprof org.eclipse.mat.api:suspects org.eclipse.mat.api:overview org.eclipse.mat.api:top_components その結果、以下の3つのzipファイルが生産され、本機jmap_に直接コピーすることができます.Leak_Suspects.zip jmap_System_Overview.zip jmap_Top_Components.zip分析結果zipファイルをローカルオープンブラウザにエクスポートして観察します.
CopyOnWriteStateTableが5.3 Gのメモリ領域を占めていることが明らかになった.Old領域で生き残る.ゴミ回収できません.このCopyOnWriteStateTableはFlinkのMemory Stateです.生産使用は推奨されません.
2.6 RocksDBの導入
そこでプログラムにrocksdb(RocksDB紹介:https://www.jianshu.com/p/73fa1d4e4273 、 https://www.ververica.com/blog/stateful-stream-processing-apache-flink-state-backends、 https://blog.csdn.net/zhangjun5965/article/details/88885534)、コードを変更してrocksDBを使用し、パスを設定します.
org.apache.flink
flink-statebackend-rocksdb_2.11
再パッケージングプログラムの実行後.13分以内にkafkaに160万件のデータを挿入し続けた.
old領域はほとんど成長しない.成長も0.01%の速度で均一に増加した.OOMの問題を解決します.Flinkプログラムは正常に動作しています.