报错原文
java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: GC overhead limit exceeded
这条通常不在节点的悬停提示里，要打开 KNIME log 才看得全。表现往往是界面卡死很久、某个节点跑到一半失败，或者整个程序无响应。
先分清是哪一种
这条流程以前跑得动，只是数据量变大了吗？
是
先调内存上限
改 knime.ini 里的最大堆内存设置，这是一行字的事，多数情况改完就好了。
否
先查流程本身
数据量没变却突然爆内存，多半是某一步让数据量意外膨胀了 – 一对多关联、透视列数暴涨、循环里越滚越大。
调内存上限
- 找到 knime.ini。它在 KNIME 的安装目录下，和主程序放在一起。改之前先复制一份备份。
- 找到以
-Xmx开头的那一行。它规定 KNIME 最多能用多少内存，比如-Xmx2048m就是最多 2 GB。默认值通常远低于机器实际内存。 - 改成机器物理内存的一半到三分之二。16 GB 的机器可以给
-Xmx8g。不要给满 – 操作系统和其他程序还要用，给满了会拖垮整台机器。 - 保存后重启 KNIME。这个设置在启动时读取，不重启不生效。
改 knime.ini 有两个注意点。一是文件可能需要管理员权限才能保存，装在 Program Files 下尤其如此。二是
-Xmx 那一行必须自成一行，不能和别的参数写在一起，格式错了 KNIME 会启动失败 – 所以要先备份。
如果是流程本身的问题
数据量没变却爆内存，按这个顺序查。
| 可疑的地方 | 怎么确认 |
|---|---|
| Joiner 一对多，行数暴涨 | 对比关联前后的行数。右表在关联列上不唯一时，左表每行会变成好几行 |
| Pivoting 列数暴涨 | 看列方向分组那一列有多少个不同取值。选到唯一值列会生成上万列 |
| 循环里数据越滚越大 | 每轮结果都被收集起来，轮数多时总量惊人 |
| 读进来的列远多于用得上的 | 看读取节点的输出有多少列。用不上的列越早删越好 |
把删列和筛行提到关联和透视之前，是最省事的优化。同样的流程，节点顺序换一下，内存占用可能差一个数量级。
怎么预防
- 装好 KNIME 后第一件事就是把
-Xmx调到合适的值，别等到出问题。 - 流程开头先删列筛行，把数据量降下来再做关联、透视、排序这些重活。
- 关联之后养成对行数的习惯。行数意外翻倍是内存问题的先兆。
- 中间结果特别大的流程，考虑把阶段性结果先写到文件，分成两条流程跑。
