这是一个奇怪的问题。我正在尝试将服务器从 Windows Server 2016 Data Center 升级到任何更新的版本。我们尝试了 2019 和 2022。此服务器是用于运行 Talend Open Studio 的 ETL 服务器，它是 MS Sql Server 和 IBM DB2 for i 之间的连接。问题是，当主机是 Windows 2019 或 2022 时，与 DB2 的连接速度会慢 100 倍，这对我们来说是不可行的。
当我们为服务器购买新的更快硬件时，我们注意到了这一点。我们在其上安装了 Windows Server 2022 Datacenter，并将 Talend 作业迁移到测试中，新服务器在运行服务器上的应用程序时速度相当快，但在连接到 DB2 时几乎停滞不前。架构如下所示：
运行 IBM i v7.2 的单个 IBM i 实例。运行 SQL Server 2014、2017 和 2019 的多台 MS SQL Server 计算机。运行 Windows Server 2016 和 Talend Open Studio (TOS) v7.3 的旧硬件上的 VM。以及运行 Windows Server 2022 和 Talend Open Studio v7.3 的新硬件上的 VM。源数据位于 SQL Server 上，这些数据由 TOS 处理并使用 JDBC 写入 DB2。
在我们的初始测试中，我们在旧的 2016 Talend 服务器上获得了每秒约 1000-1200 行的吞吐量。令人费解的是，新硬件每秒只能管理 17-20 行。在 IBM i 上，相同的作业池正在处理所有 ODBC/JDBC 请求。在较新的 Talend Server 上，从 SQL Server 进行的初始读取比在较旧的 Talend Server 上快得多，并且两个服务器都使用相同的 DB2 JDBC 驱动程序，即 jtOpen 9.8。唯一的区别是 Windows 2016（快）与 Windows 2022（慢）以及每个服务器上加载的 JVM，一个使用 Java 8，而另一个使用 Java 11。
我们的基础设施人员找不到 Windows 服务器之间任何实质性的配置差异，并且在网络上，从 Talend 服务器到 IBM i 只有一个跳（它们都在同一个子网上）。
基础设施启动了两个相同的虚拟机来测试 Windows。他们在一台服务器上放置了一个空的 Windows 2016 服务器，在另一台服务器上放置了一个空的 Windows 2022 服务器。我在两台服务器上都安装了 Java 11、Talend 7.3 和相同的测试 Talend 模型。两台 Talend 服务器都连接到同一个 SQL Server 用于输入，并连接到同一个 IBM i 用于输出。Windows 2016 服务器在新硬件上每秒管理大约 2000 行，而 Windows 2022 服务器每秒仅管理 19 行。我们启动了一个与其他两台相同的新虚拟机，并在其上安装了 Windows 2019。我在上面安装了相同的 Java 和 Talend 软件，但它每秒只能管理 20 行。我在 Windows 2022 服务器上将 Java 升级到 Java 17，并安装了一份 Talend v8.0。它每秒只能管理 17 行。
那么我下一步该怎么做呢？我们真的不想被困在旧版本的 Windows 中，但我们的一些数据迁移工作在旧硬件上需要 13 到 18 个小时。而在较新的 Windows 服务器上则需要几个月的时间。
是什么原因导致速度变慢？唯一的区别是 Windows 2016 相对较快，而 Windows 2019/2022 则慢 100 倍。
注意：没有错误，只是运行缓慢。
答案1
我们在使用 Talend Cloud Edition 2022-11 版时也遇到了同样的问题。Talend 和 DB2 for i 总是很慢。但迁移到 Windows Server 2016、2019 或 2022 时情况更糟。在 2023-04 版本中，Talend 对连接参数进行了修复。默认情况下，该Statement.RETURN_GENERATED_KEYS参数处于活动状态并导致写入缓慢。现在默认情况下已禁用它，性能恢复，甚至比以前更好。
我建议您迁移到最新版本或至少是 2023-04 版本。
答案2
在我看来，JDBC 连接属性或 Talend 进程的配置确实存在差异。不确定配置如何在原始配置和新配置之间移动。
假设直接在 IBM i 的 Db2 中执行 INSERT 操作，我见过的两个最大的吞吐量限制因素是
- 单行插入而不是批量插入多行
- 在不使用提交控制的情况下将数据写入 i 上的日记表。
你可能想看看追踪属性
“服务器跟踪”
指定 JDBC 服务器作业的跟踪级别。启用跟踪后，跟踪在客户端连接到服务器时开始，在连接断开时结束。必须在连接到服务器之前启动跟踪，因为客户端仅在连接时启用服务器跟踪。
- “0”（跟踪未激活）
- “2”（启动JDBC服务器上的数据库监视器作业）
- “4”（在 JDBC 服务器作业上启动调试）<-“8”（在 JDBC 服务器作业结束时保存作业日志）
- “16”（在 JDBC 服务器作业上启动作业跟踪）
- “32”（保存SQL信息）
- “64”（支持启动数据库主机服务器跟踪） 将这些值相加可以启动多种类型的跟踪。例如，“6”启动数据库监视器并启动调试。
“工具箱跟踪”
指定要记录的 IBM Toolbox for Java 跟踪的类别。跟踪消息对于调试调用 JDBC 的程序很有用。但是，记录跟踪消息会导致性能下降，因此此属性仅针对调试设置。跟踪消息将记录到 System.out。
- “”
- “没有任何”
- “datastream”（记录本地主机和远程系统之间的数据流）
- “诊断”（记录对象状态信息）
- “错误”（记录导致异常的错误）
- “信息”（用于跟踪代码中的控制流）
- “警告”（可恢复的日志错误）
- “转换”（记录 Unicode 和本机代码页之间的字符集转换）
- “代理”（记录客户端和代理服务器之间的数据流）
- “pcml”（用于确定 PCML 如何解释发送到服务器和从服务器发送的数据）
- “jdbc”（记录jdbc信息）
- “全部”（记录所有类别）
- “thread”（记录线程信息）
最后，JTOpen 9.8 已经发布很久了......于 2019 年 4 月发布。
我可能会尝试一个较新的版本，看看是否有所不同。