跳到主要内容
版本:Next

调优指南

本文为大家介绍 SeaTunnel Engine 的调优方法,帮助用户根据实际需求优化 SeaTunnel Engine 的性能和稳定性。 阅读次篇前请知晓,当前指南结合的是大部分用户的真实使用情况总结而成,可能并不适用于所有场景,用户可以根据实际情况进行调整。

SeaTunnel Engine 是基于 [JVM] (https://zh.wikipedia.org/wiki/Java%E8%99%9A%E6%8B%9F%E6%9C%BA) 运行的数据集成引擎,所以 JVM 部分的调优对 SeaTunnel Engine 同样适用,这里就不再赘述。

集群响应缓慢或假死

JVM

如果 SeaTunnel Engine 集群响应缓慢或假死,可能是由于 JVM 堆内存不足导致的。可以通过以下步骤进行排查:

堆内存不足

排查流程
  1. 检查 JVM 堆内存实时占用 使用 jcmd 命令查看 JVM 堆内存使用情况, 其中 <pid> 是 SeaTunnel Engine 进程的 PID。
    jmap -heap <pid>
    输出结果示例:
     Attaching to process ID 2111950, please wait...
    Debugger attached successfully.
    Server compiler detected.
    JVM version is 25.192-b12

    using thread-local object allocation.
    Garbage-First (G1) GC with 13 thread(s)

    Heap Configuration:
    MinHeapFreeRatio = 40
    MaxHeapFreeRatio = 70
    MaxHeapSize = 17179869184 (16384.0MB)
    NewSize = 1363144 (1.2999954223632812MB)
    MaxNewSize = 10301210624 (9824.0MB)
    OldSize = 5452592 (5.1999969482421875MB)
    NewRatio = 2
    SurvivorRatio = 8
    MetaspaceSize = 21807104 (20.796875MB)
    CompressedClassSpaceSize = 1073741824 (1024.0MB)
    MaxMetaspaceSize = 2147483648 (2048.0MB)
    G1HeapRegionSize = 8388608 (8.0MB)

    Heap Usage:
    G1 Heap:
    regions = 2048
    capacity = 17179869184 (16384.0MB)
    used = 2997548048 (2858.684585571289MB)
    free = 14182321136 (13525.315414428711MB)
    17.448026034981012% used
    G1 Young Generation:
    Eden Space:
    regions = 348
    capacity = 10737418240 (10240.0MB)
    used = 2919235584 (2784.0MB)
    free = 7818182656 (7456.0MB)
    27.1875% used
    Survivor Space:
    regions = 10
    capacity = 83886080 (80.0MB)
    used = 83886080 (80.0MB)
    free = 0 (0.0MB)
    100.0% used
    G1 Old Generation:
    regions = 0
    capacity = 6358564864 (6064.0MB)
    used = 0 (0.0MB)
    free = 6358564864 (6064.0MB)
    0.0% used
    重点关注G1 Old Generation的使用情况,如果 Old Generation 的使用率接近 100%,则可能是堆内存不足导致的。
  2. 检查日志 系统会不定期输出健康监控日志,检查 SeaTunnel Engine 的日志,查看是否有频繁的 Full GC 或者长时间的 GC 暂停,这可能是由于堆内存不足导致的。 下边是一个日志示例:
    [] 2025-07-04 16:42:54,818 INFO  [c.h.i.d.HealthMonitor         ] [hz.main.HealthMonitor] - [127.0.0.1]:5801 [seatunnel] [5.1] processors=16, physical.memory.total=31.1G, physical.memory.free=9.7G, swap.space.total=0, swap.space.free=0, heap.memory.used=198.7M, heap.memory.free=15.8G, heap.memory.total=16.0G, heap.memory.max=16.0G, heap.memory.used/total=1.21%, heap.memory.used/max=1.21%, minor.gc.count=2, minor.gc.time=44ms, major.gc.count=0, major.gc.time=0ms, load.process=0.00%, load.system=66.67%, load.systemAverage=5.66, thread.count=118, thread.peakCount=118, cluster.timeDiff=0, event.q.size=0, executor.q.async.size=0, executor.q.client.size=0, executor.q.client.query.size=0, executor.q.client.blocking.size=0, executor.q.query.size=0, executor.q.scheduled.size=0, executor.q.io.size=0, executor.q.system.size=0, executor.q.operations.size=0, executor.q.priorityOperation.size=0, operations.completed.count=13, executor.q.mapLoad.size=0, executor.q.mapLoadAllKeys.size=0, executor.q.cluster.size=0, executor.q.response.size=0, operations.running.count=0, operations.pending.invocations.percentage=0.00%, operations.pending.invocations.count=0, proxy.count=9, clientEndpoint.count=0, connection.active.count=0, client.connection.count=0, connection.count=0
    重点关注:
    • heap.memory.used/max:堆内存使用率,如果接近 100%,则可能是堆内存不足。
    • major.gc.countmajor.gc.time :如果 Full GC 频繁,可能是堆内存不足导致的。 可以通过持续查看日志来判断是否存在频繁的 Full GC 或者长时间的 GC 暂停。
解决方案

通过降低任务并发和任务数量来降低同一时间的内存占用。如果确实需要更多的内存,请参考 安装部署 中的配置 SeaTunnel Engine JVM 选项来增加内存。

内存无限制占用
  1. 生成内存快照

    有些时候,我们的任务量固定,但是内存使用量却不断增加,这可能是由于任务中存在内存泄漏导致的。请dump下对应的内存快照信息。

    jmap -dump:live,format=b,file=heap.hprof <pid>

    然后使用 Eclipse Memory Analyzer 等工具分析内存快照,查找内存泄漏的原因。 针对非二开的用户或者连接器,也可以创建一个 issue 并附上内存快照,我们会帮助您分析。

  2. 打印对象占用排行

    有些时候,生成内存快照会随着JVM的假死而失败,这时可以尝试打印对象占用排行来查看内存使用情况。

    jmap -histo:live <pid> | head -n 100

    同样的,可以通过分析输出结果来查找内存泄漏的原因。 针对非二开的用户或者连接器,也可以创建一个 issue 并附上对象占用信息,我们会帮助您分析。

CPU占用率过高

CPU占用率过高也是一个集群节点假死的常见原因,但是出现概率基本没有内存占用过高的情况高。可以通过以下步骤进行排查:

排查流程
  1. 检查 CPU 占用率
    • 使用 tophtop 命令查看 SeaTunnel Engine 进程的 CPU 占用率。
    • 如果 CPU 占用率接近 100%,则可能是 CPU 资源不足导致的。如果有多个核,需要考虑多个核的占用率。
解决方案

如果 CPU 占用率过高,可以尝试以下解决方案:

  • 降低任务并发和任务数量,减少 CPU 资源的占用。
  • 增加集群节点数量,分担 CPU 资源的压力。

Hazelcast

Hazelcast相关的配置也是影响 SeaTunnel Engine 性能的重要因素。可以通过修改hazelcast.yaml系列文件的配置参数修改,请参考 安装部署 。 以下是一些常见的调优参数:

  • hazelcast.operation.generic.thread.count: 该参数控制 Hazelcast 的通用操作线程数。SeaTunnel Engine 使用此线程用于执行RPC请求。可以根据实际情况调整该参数,以提高 Hazelcast RPC 的性能。 如果监控到日志中频繁出现如下类型日志,同时CPU占用率不算很高。请尝试调高该参数:
2024-09-03 06:15:45,807 WARN  [.s.i.o.s.SlowOperationDetector] [hz.main.SlowOperationDetectorThread] - [seatunnel-worker-1]:5802 [seatunnel] [5.1] Slow operation detected: