源数据库

• Oracle 19c，本地，CDB
• 数据库主机的I/O带宽为6 GB/s，由此主机上运行的所有数据库共享
• 临时表空间由42个文件组成，每个文件大小为32 GB，由数据库上运行的所有进程共享
• 注意：如果有太多并行线程且数据量大（例如，在覆盖语句中对大表使用order by子句），可用空间可能达到上限。

Kafka Connect

• 3个节点，RHEL虚拟机，每个节点有12个CPU，62 GB RAM，40 GB JVM
• Kafka CP 7.7.1
• Debezium 3.0，部署在Kafka Connect上

监控

• Prometheus和Grafana

测试结果

在我的测试中，我主要关注性能相关的属性。这些属性包括：

• 在Debezium方面：
  • snapshot.max.threads
  • snapshot.fetch.size
  • max.batch.size
  • max.queue.size
  • poll.interval.ms
• 在Kafka Connect方面：
  • batch.size
  • linger.ms
  • compression.type

我在测试中尝试了这些属性，并获得了有趣的见解。在这一点上，我已经揭示了在我们的情况下证明最有效的设置：

• producer.override.batch.size: 1000000，
• producer.override.linger.ms: 500，
• producer.override.compression.type: lz4，

通过使用这些设置，我们能够实现25%的优化：从最初的8小时，我们将完整快照的时间缩短到了6小时（见图1）。在整个快照过程中，CPU消耗和JVM内存使用量都没有超过80%。

我特别观察了一个指标，即源记录的轮询速率。在我的测试中，这个指标作为一个有用的第一指示器，用于判断性能是好还是坏。正如图2所示，最大速率为每秒90k个操作。无论如何，我都无法达到更高的速率。同样重要的是，要查看其相邻的指标源记录写入速率，该指标应该显示几乎相同的图表：

如果轮询是正常的，但推送到Kafka的速度不够快，那么源记录活动计数可能是一个标识符。图3显示，在我们的情况下，我们不必担心任何阻塞情况

当然，我们尽力提高速度，并测试了一些其他设置和它们的组合。以下是结果：

• 将snapshot.fetch.size更改为5000、50000或200000：没有改进
• 将batch.size更改为800000或2000000：没有改进
• 将linger.ms更改为10或100：没有改进
• 将linger.ms更改为750或1000：导致更多时间花费在GC上
• 将max.batch.size更改为4000或8000：没有改进
• 将max.batch.size更改为8000，max.queue.size更改为16000，snapshot.fetch.size和query.fetch.size更改为50000：没有改进，更多时间花费在GC上，CPU消耗更高
• 将poll.interval.ms更改为100：没有改进
• 这些尝试都没有带来任何改进，大多数情况下速度反而更慢。将snapshot.max.threads的值设置为我们从中提取数据的表的总数也没有加速过程，而且由于对共享数据库资源的巨大负载，这种设置也很微妙。使用过多的并行线程，我们甚至遇到了连接器崩溃的情况，原因是“ORA-12801：在并行查询服务器中发生错误”。