记一次flume OOM异常处理 “lifecycleSupervisor-1-46“

最新推荐文章于 2024-06-23 16:31:00 发布

刘乘九

最新推荐文章于 2024-06-23 16:31:00 发布

阅读量434

点赞数 1

文章标签： flume 实时大数据 jvm java 大数据

本文链接：https://blog.csdn.net/weixin_39877754/article/details/117413629

版权

背景

一个flume任务里包含了九种日志的传输任务。使用Taildir模式配合linux的定时任务切换读取目录的软连接。

现象

1.查看flume最后的日志信息
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "lifecycleSupervisor-1-46"
Exception in thread "PollableSourceRunner-TaildirSource-cost_source" java.lang.OutOfMemoryError: Java heap space

2.检查各类日志的最后更新时间和kafka的最终接受时间，发现各类日志的传输到kafka的延迟有1-4分钟。

解决方案

1. 直接增加flume JVM的可用的总内存大小。注意尽量将Xms（初始化占用内存）和Xmx（最大占用内存）设置成一样的值，避免因为内存抖动造成的OOM。对/XXX/flume/conf/flume-env.sh文件内容进行修改（新安装的可以将flume-env.sh.template文件改名后修改内容）

export JAVA_OPTS="-Xms6144m -Xmx6144m -Dcom.sun.management.jmxremote"

2.以TAILDIR模式下为例，对没每个source设置batchsize，避免因为数据太多造成数据积压。分批进行读取处理。

bi_task.sources.login_source.type     = TAILDIR

bi_task.sources.login_source.filegroups = login_file_group

bi_task.sources.login_source.filegroups.login_file_group = /XXX/.*_LOGIN_.*.log

bi_task.sources.login_source.positionFile = /XXX/flume/flume-positionFile/logLoginPositionFile.json
bi_task.sources.login_source.batchSize     = 10000

3.在多个channel的情况下（比如这次处理的一个任务中包含了九种日志，所以实际上有九个source、channel及sink），如果使用内存Channel一定根据任务情况对各个channel的byteCapacityBufferPercentage参数进行自定义设置。否则任务中申明的channel过多可能会造成限制的内存上限超出100%，该参数的默认值为20%。

Property Name	Default	Description
type	-	类型指定为：memory
capacity	100	存储在channel中的最大容量
transactionCapacity	100	从一个source中去或者给一个sink，每个事务中最大的事件数
keep-alive	3	对于添加或者删除一个事件的超时的秒钟
byteCapacityBufferPercentage	20	定义缓存百分比
byteCapacity	-	Channel中允许存储的最大字节总数

4.增大sink的吞吐量，以kafka sink 为例。可以根据情况适当增加kafka的flumeBatchSize（批量写入的数据量）。增加吞吐量的同时也会降低数据的实时性。

分析

1.查看flume源码，发现报错信息的"PollableSourceRunner-TaildirSource-cost_source"的初始化主要逻辑是获取所有可执行的ChannelProcessor（主要功能是进行监控及将数据从source推到channel）并进行初始化。监控到的文件内容比较大，一次性source载入了过多数据，应该设置批量载入数据的数量。

2.有两种的日志量通常占所有日志量的50%左右。应该对其channel的内存进行独立配置，尤其是内存百分比应该尽量按数据量进行分配更合理，不然默认一个channel持有20%，压力的情况下内存可能会出现分配180%的情况（9个channel * 20%）的特殊情况。

3.sink单次向kafka写入的数据量较小，导致耗费过多时间与kafka建立连接。增大写入的数据量可以提升sink的消费速度，避免数据在channel里造成堆积造成内存溢出。