抽象的
由于更高的时钟速度和可用内核数量，当前 CPU 的处理能力得到提高，Informix 部署产生了更高的事务吞吐量。在 12.10 及更早的产品中依赖逻辑日志重放（HDR、RSS、SDS）的复制技术达到了设计限制，在峰值负载下，辅助实例可能需要大量时间才能赶上主实例。在 14.10 中，对逻辑日志传输和重放机制进行了彻底改革，从而大大提高了速度，现在支持无延迟复制，与以前的 Informix 版本（12.10.xC12 和更早版本）相比，事务率高达 5 - 8 倍. 另一个受影响的领域是崩溃恢复——Informix 14.10.xC1 可以在崩溃后更快地联机。
本文档重点介绍了 14.10.xC1 中的复制性能改进，可作为 Informix 集群性能调优的参考。
概括
下图显示了 Informix 14.10.xC1 与截至撰写本文时针对各种类型辅助服务器的最后一个版本的 Informix (12.10.xC12) 相比的性能改进。
远程独立辅助 (RSS) - 日志重放性能与 12.10 相比提高了 7 倍：
（x 轴以每秒百万条日志记录为单位，值越高越好）
共享磁盘辅助 (SDS) - 日志重放性能相比12.10 好 5 倍以上：
（x 轴以每秒数百万条日志记录为单位，数值越高越好）
与 12.10 相比，采用高可用性数据复制 (HDR) 设置的事务持续速率提高 5 倍以上
（x 轴以每分钟数百万笔交易为单位，值越高越好）
Informix 14.10 从崩溃中恢复，超过 10 亿条未完成记录与 12.10 相比快 4 倍
（x 轴是以分钟为单位的时间，值越低越好）
细节
RSS 日志重播率与主服务器上的逻辑日志记录率
为了更好地理解 Informix 14.10 中的复制性能改进，我们需要查看不同条件下的集群行为，以及产生不同级别事务活动的工作负载。在轻负载下，任何类型的辅助实例都能够与主实例保持同步，只要辅助实例重放逻辑日志的能力匹配或超过主实例上生成逻辑日志记录的速率。因此，为了研究复制性能，需要一个能够生成高级事务活动的环境。类似于行业标准 TPC-C 的基准测试似乎很合适，因此被选中用于此练习。
带有 RSS（远程独立辅助）的 Informix 设置用于执行 OLTP 基准测试并测量事务率、主节点上的逻辑日志记录速率和辅助日志重放率。OLTP 吞吐量，仅计算新订单事务，达到百万 tpm（总事务率超过 50,000 每秒），逻辑日志以每秒超过 110 万条记录的速度写入。使用 Informix 14.10 和 12.10 以不同的工作负载执行了几个 8 分钟的基准测试运行，在所有情况下都等到 RSS 赶上主系统。然后，计算基准测试处于活动状态时的窗口的日志重播率，以及基准已完成且主节点空闲时除了将剩余事务（日志）传输到 RSS 之外的时段。
下图显示了作为逻辑日志记录率函数的日志重播率，均以每秒数百万条记录为单位。线性区域表示 RSS 可以在没有延迟或延迟最小的情况下跟上主节点的范围。
| 主节点负载稳定的 RSS 日志重播率 | 主节点负载适中或无负载的峰值 RSS 日志重播率 |
| |
|
每个基准运行持续大约 8 分钟，并执行以在 Informix 主服务器上产生不同但稳定的事务负载水平。这允许确定 RSS 仍然可以跟上的最大速率，还可以查看当逻辑日志写入速度超过辅助节点上的重放能力时会发生什么。下图显示了一组具有不同事务负载的基准执行的次要日志重播率（y 轴，每秒数百万条记录）与以分钟为单位的时间（x 轴）。
| RSS可以跟上或赶上 | 事务（日志）率大于 RSS 重播率 |
| |
|
包含基准运行“A”到“H”的图显示了“F”、“G”和“H”清晰可见的明显模式，其中日志重播率不会立即匹配基准生成的逻辑日志率，而是逐渐增加。这是由重要的物理日志记录活动引起的，该活动在基准测试开始时最高，并且随着时间的推移变得不那么强烈。当 physlog 活动减弱时 - 二次应用率增加，超过基准生成的逻辑日志率。日志重播率继续增加，直到 RSS 赶上主要。缓慢的物理日志记录可能会限制 OLTP 工作负载的日志重播率。将 Informix RSS 物理日志放置到具有更好功能的设备或存储子系统中，将使 RSS 能够更快地赶上主要的。
下面显示了基准运行“H”的 RSS（物理日志）和 Primary（逻辑日志）上的日志 I/O，与日志重放率相关（x 轴是以分钟为单位的时间）：
| RSS 日志重播率和日志 I/O |
| |
基准测试在 RSS 上的日志 I/O 运行“K”，其中基准运行大约 8 分钟，并在主节点上以每秒超过 110 万条的速率生成日志记录：
| 主节点处于高事务负载时的 RSS 日志重播率和日志 I/O |
| |
在高事务负载期间，如上图所示，主节点上的逻辑日志设备经历了极高的 I/O 活动，同时读取和写入。拥有可以支持这种 I/O 模式的存储子系统非常重要，可能为逻辑日志使用单独的设备或 I/O 通道。同样，用于 RSS 物理日志的存储设备的 I/O 能力应该适合预期的事务峰值速率。还必须注意的是，随着日志重放性能的提高 - 网络带宽和主要和次要之间的链路延迟可能会成为限制因素。
共享磁盘辅助
为 Informix 主和 SDS（共享磁盘辅助）对收集了类似的数据。
下图显示了 Informix 14.10（蓝线）和 12.10（红线）之间的日志重播率与主节点上的逻辑日志记录率的比较。Y-Axis 是逻辑日志重放率，X-Axis 是逻辑日志记录率，均以每秒百万条记录为单位。线性区域表示 SDS 在没有延迟或延迟最小的情况下跟上初级的范围。
| 主节点负载稳定的 SDS 日志重播率 | 峰值 SDS 日志重播率，主节点负载适中或无负载 |
| |
|
在基准测试开始时影响 RSS 重播率的物理日志记录在 SDS 中不是问题。下图表示不同级别的事务活动的 SDS 重播率（y 轴）与以分钟为单位的时间（x 轴），显示目标应用率 - 高达配置支持的最大值 - 可以由 SDS 辅助毫不拖延，如左图所示，线 A 到 I。然而，在或接近初级峰值负载时，我们看到 SDS 次级的重播率受到影响，如右图所示 - 线 J、K、 L.
| SDS跟上初级 | 主节点上的日志率超过 SDS 重播率 |
| |
|
逻辑日志的高性能存储子系统仍然是 SDS 的关键要求。
高可用性数据复制
使用 Informix HDR，针对 HDR_TXN_SCOPE 设置为 NEAR_SYNC 和 ASYNC (DRINTERVAL = 0) 以及 DRINTERVAL = 1 的配置执行基准测试。在基准测试环境中，当 HDR_TXN_SCOPE 设置为 ASYNC 时，可以观察到 Informix 14.10 的最佳结果。使用 HDR - 主节点上的事务速率受次节点应用速率的限制，因此性能指标是可实现的最大基准吞吐量。为 HDR 的性能改进提供一个数字是一项挑战，因为基准吞吐量取决于工作负载的具体情况，并且在 12.10 和 14.10 的相同设置中可能无法实现最大吞吐量。下面是显示吞吐量的图（y 轴，
| |
|
将 DRINTERVAL 设置为“1”时，性能类似于“ASYNC”，但对于具有 ASYNC 事务范围的 Informix 14.10，测量的事务延迟与 DRINTERVAL=1 的配置相比要少。总体而言，在所有测试的 HDR 配置中，与 Informix 12.10 相比，Informix 14.10 表现出显着的性能改进。
崩溃恢复
与所有以前的版本相比，改进的日志重播率还使 Informix 14.10 在崩溃后恢复得更快。
该图显示了在使用“kill -9”终止实例后 Informix 14.10 恢复期间收集的数据，自上次检查点以来未处理超过 50 亿条日志记录。在恢复期间，日志重播率超过每秒 60 万条记录。与 Informix 12.10 相比，Informix 14.10 达到完全运行状态的速度快了 4 倍。
配置和调整
在 Informix 14.10 中，很少有配置参数可以调整以获得更好的日志重放性能。最佳配置取决于部署 Informix 实例的硬件环境以及工作负载的具体情况，但此处的注释可以作为一个很好的起点。
SMX_NUMPIPES 2
主服务器和辅助服务器之间的 SMX 网络连接数。通常相当小的数量就足够了。推荐值为 2。
日志缓冲区 2048
逻辑日志缓冲区的大小，以 KB 为单位。还确定复制缓冲区的大小（请参阅 SEC_DR_BUFS）。在基准环境中，使用了 LOGBUFF = 2048 的缓冲日志记录。有一种观点认为，使用无缓冲日志记录时，日志缓冲区大小越小越好，但这并不完全正确。大多数生产工作负载都有大量活动并发会话，使用更大的日志缓冲区会产生更好的性能。无论逻辑日志模式如何，即使是中型实例也可以从将其设置为 >= 1024 中受益。具有无缓冲日志模式的较小日志缓冲区大小将仅对一个或少量并发会话执行得更好。
LTAPEBLK 20480
主服务器使用此配置参数来备份逻辑日志。在辅助 4 个 LTAPEBK 大小的缓冲区上，用于重放日志记录。
SEC_DR_BUFS 24
在 14.10.xC1 中引入 - 复制缓冲区的数量。适用于 RSS、SDS、HDR 二级和带 HDR 的初级。缓冲区大小与 LOGBUFF 配置参数设置的相同。最小值（默认）值 = 12，最大值 = 128
SEC_LOGREC_MAXBUFS 1000
在 14.10.xC1 中引入 - 用于重播日志记录的 16k 日志缓冲区的数量。在独立/主实例上，它在崩溃恢复期间生效。最小（默认）值为 4 x OFF_RECVRY_THREADS。超过 5000 的值可能会对性能产生负面影响。
OFF_RECVRY_THREADS 11
用于日志重放的逻辑恢复线程数。在辅助服务器上 - 不应超过 CPUVP 的数量和/或实例可用的处理器内核数量，尤其是当 SEC_APPLY_POLLTIME 设置为“0”以外的值时。在崩溃恢复期间，此参数被忽略，恢复线程数设置为配置的 CPUVP 数的两倍。推荐的最小值为 5，因此对于 CPUVP 数量为 5 或更少的辅助配置，SEC_APPLY_POLLTIME 参数可能应保留为默认值 - “0”。
SEC_APPLY_POLLTIME 0
在 14.10.xC1 中引入 - 时间，以微秒为单位，日志重播线程在产生之前轮询事件。重播日志记录时可以减少线程上下文切换开销。
设置为非零值可能会导致日志重放期间 CPU 利用率增加，并且需要考虑更改其他 Informix 配置参数：
- 可能需要将轮询线程移至 NETVP (NETTYPE)
- 当 SEC_APPLY_POLLTIME 不为 0 时，建议设置 number的 OFF_RECVRY_THREADS 小于 CPUVP 数和/或 Informix 实例可用的处理器内核数（对于具有 64 个 CPUVP 并在具有 64 个逻辑处理器且每个内核有 8 个线程的系统上运行的 Informix 实例，将 OFF_RECVRY_THREADS 设置为小于 16）
在基准环境中，当 SEC_APPLY_POLLTIME 设置为 40 时，某些配置的性能更好，但是当 SEC_APPLY_POLLTIME 为 0 时，在更广泛的条件下性能更好。建议使用类似于生产的工作负载调整此参数。可以使用“onmode -wm”或“onmode -wf”动态更改。
RSS_FLOW_CONTROL
SDS_FLOW_CONTROL
为了获得更好的性能，可以通过在主服务器上将适当类型的辅助服务器上的此参数设置为“-1”来禁用流量控制。可以使用“onmode -wm”或“onmode -wf”动态更改。
RSS_NONBLOCKING_CKPT 1
在 14.10.xC1 中引入。仅适用于远程独立辅助服务器 (RSS) - 启用非阻塞检查点。在检查点进行时，会继续重播日志。默认为“0”（在检查点期间阻止 RSS 上的日志重播）
DRINTERVAL 0
HDR_TXN_SCOPE 异步
仅适用于 HDR 辅助服务器。在基准测试环境中，这会带来更好的整体性能。如果 HDR_TXN_SCOPE 必须设置为 NEAR_SYNC - Informix 14.10 中的优化可能会在无缓冲日志模式下产生更好的性能。当 DRINTERVAL 不为 0 时，HDR_TXN_SCOPE 参数不适用，基准中的 DRINTERVAL = 1 性能接近最佳，但 DRINTERVAL = 0 和 ASYNC 事务范围 - 辅助事务延迟明显减少。
LOG_STAGING_DIR
在检查点处理期间将缓冲池刷新到磁盘时，必须将其设置为有效的目录位置才能在 HDR 中启用日志暂存。对于 RSS 服务器，日志暂存目录配置是启用延迟应用或停止应用的要求。可以使用 onmode -wf 或 onmode -wm 动态设置此配置参数。
结论
大量的开发工作促成了最新的 Informix 版本的交付，在大多数复制和高可用性领域都有了重大的性能改进。使用 Informix 14.10 - RSS、SDS 和 HDR 集群现在可以支持更高的事务负载，事务实际上实时传播到辅助服务器。
在辅助服务器上，对逻辑和物理日志空间的读取和写入需要同步 I/O 操作。出于性能原因，建议使用支持大量 IOPS（每秒 I/O 操作）的存储，最好是基于闪存或至少 SSD（固态磁盘）介质用于日志空间。