Kafka Connect JDBC Source任务出现OutOfMemoryError问题求助

咱先从紧急恢复到根源排查一步步来，毕竟小表正常大表炸内存，核心问题基本出在批量处理和资源配置上：

一、先恢复服务器可用性 #

当前服务器已经无响应，先把服务拉起来再说：

• 强制重启Kafka Connect进程/集群，释放占用的内存。如果重启前还能操作，优先抓取堆转储文件，用命令jmap -dump:format=b,file=connect_heap.hprof <connect进程PID>，这对后续定位内存泄漏或过载问题至关重要。
• 重启后先暂时停掉这个大表的同步任务，避免再次触发OOM。

二、从JDBC连接器配置找根源（重点！） #

小表正常、大表出问题，说明默认的批量配置扛不住大表的数据量级，调整以下几个关键参数：

• 缩小单次拉取的行数：默认的batch.max.rows是1000，大表每行数据如果量大，一次拉1000行直接把内存撑爆。改成更小的值，比如"batch.max.rows": "200"，根据你的数据大小逐步调整，减少单次加载到内存的数据量。
• 给时间戳字段加索引：你用的是mode=timestamp，如果dateColumn没有索引，每次poll都会全表扫描，不仅慢还会把大量历史数据加载到内存。赶紧给这个字段加个索引，让连接器能快速定位增量数据，避免无差别加载。
• 缩短poll间隔：当前poll.interval.ms是5分钟，这期间大表可能产生了巨量数据，一次拉取压力太大。改成1分钟甚至更短，比如"poll.interval.ms": "60000"，分多次拉取分散内存压力。
• 可选：用自定义查询过滤字段：如果不需要同步全表字段，把table.whitelist换成query配置，只拉取必要字段，比如：

  "query": "SELECT id, dateColumn, critical_field1, critical_field2 FROM tableName WHERE dateColumn > ?"
  

  减少单条消息的内存占用。

三、优化Kafka Connect的JVM内存配置 #

Kafka Connect本身的堆内存可能不够用：

• 找到Connect的启动配置（比如connect-distributed.sh里的KAFKA_HEAP_OPTS），默认堆内存可能只有2G左右，对于大表同步远远不够。根据服务器硬件调整，比如服务器有16G内存的话，改成：

  export KAFKA_HEAP_OPTS="-Xms4G -Xmx8G"
  

• 同时建议启用G1垃圾收集器，减少Full GC的停顿和内存溢出风险：

  export KAFKA_JVM_PERFORMANCE_OPTS="-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:ParallelGCThreads=8"
  

四、用监控和日志定位细节 #

• 打开Connect的DEBUG日志，重点看JDBC连接器的拉取日志，比如每次拉了多少行、数据量大小，确认是不是单次拉取的数据量超标。
• 用JMX监控Connect的内存指标，比如查看kafka.connect:type=connector-metrics,connector=jobName下的batch.size.avg、records.per.request.avg，直观看到批量处理的压力。
• 如果之前抓了堆转储，用MAT（Memory Analyzer Tool）分析，看是哪个对象占用了大量内存——比如是不是ResultSet没及时释放，或者JSON序列化后的消息体积过大。

五、进阶优化方案 #

如果以上调整还不够，可以试试这些：

• 分区并行同步：给大表按dateColumn或者其他字段做分区，用partition.column.name配置让多个任务并行拉取不同分区的数据，分散单进程的内存压力，同时调高tasks.max的值（比如改成4）。
• 换用更高效的序列化方式：默认的JSON序列化内存占用较高，换成Avro序列化（配合Schema Registry），能大幅减少单条消息的内存占用。
• 分阶段同步：先同步历史数据（比如按日期分段拉取），再开启增量同步，避免一次性加载全量历史数据导致OOM。

内容的提问来源于stack exchange，提问作者Shlomo