程涛-supertim1. 问题现象与初步排查
最近在数据迁移项目中频繁遇到Kettle作业卡死在表输入和表输出环节的情况。具体表现为：作业运行到某个表输入或表输出步骤时，进度条长时间停滞，CPU占用率异常升高，但数据库连接并未断开。这种卡死现象通常发生在处理10万行以上的数据表时，且没有固定规律，有时在开始阶段就卡住，有时则在处理到70%-80%数据量时突然停滞。
通过JVisualVM监控工具观察发现，卡死时Java堆内存占用曲线呈现平台期，但并未达到配置的最大堆内存值（-Xmx4g）。更奇怪的是，即使手动停止作业，Kettle界面也会无响应长达3-5分钟。这提示我们问题可能不仅与内存有关，还涉及线程阻塞或资源锁争用。
关键提示：当Kettle卡死时，不要立即强制终止进程。建议先通过
jstack <pid>命令获取线程快照，这能帮助定位死锁或长时间阻塞的线程。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 深度原因分析
2.1 数据库连接池配置不当
多数情况下，表输入/输出卡死的根本原因是数据库连接池资源耗尽。Kettle默认使用GenericConnectionPool，其配置参数隐藏在$KETTLE_HOME/.kettle/kettle.properties文件中。常见问题包括：
- 未设置合理的连接超时（connectTimeout）
- 连接池最大大小（maxActive）与并发步骤数不匹配
- 连接泄漏导致可用连接数逐渐减少
通过以下SQL可以验证连接池状态（以MySQL为例）：
sql复制SHOW STATUS LIKE 'Threads_connected';
SHOW PROCESSLIST;
2.2 事务隔离级别冲突
当源表和目标表位于同一数据库实例时，默认的REPEATABLE READ隔离级别可能导致锁等待。特别是在以下场景：
- 表输入步骤长时间运行大查询
- 表输出步骤使用批量插入（batch update）
- 作业中同时存在更新和查询同一张表的步骤
建议解决方案：
properties复制# 在表输入步骤的"选项"标签页添加连接参数
useCursorFetch=true
defaultFetchSize=500
transactionIsolation=READ_COMMITTED