过去几年里，我曾在许多论坛中谈论过，非代码贡献对于 MariaDB Server 和我们 MariaDB Foundation 来说，与我通常协助的代码贡献同等重要。过去我也曾强调过英特尔如何提供了许多精彩的非代码贡献。他们通过检测其新平台和未来平台上的性能问题来协助我们，并指导我们找到这些问题的根本原因。
成果：在 HammerDB 中达到百万以上的 NOPM
今天我想讨论英特尔协助实现的一些性能改进，这些改进使得 MariaDB Server 在 HammerDB TPROC-C 测试中达到了 100 万 NOPM（每分钟新订单）的成绩。这得益于英特尔提交的问题报告，例如 MDEV-33515（log_sys.lsn_lock 导致过多的上下文切换）以及 InnoDB 团队的 Marko 提交的相关拉取请求。
在深入细节之前，我还要感谢 Marko Mäkelä 在提交信息中将发现归功于英特尔的 Steve Shaw，他是一位出色的开源贡献者。
问题：锁争用——与平台相关！
在英特尔的测试中，他们注意到 InnoDB 中存在针对特定锁的争用。在大多数可扩展并行运行多线程的应用程序中，总会存在需要串行化的点。这是为了防止同时读写同一块内存，或者确保数据以正确的顺序写入磁盘，避免不同数据相互覆盖。
当大量线程试图访问同一个代码路径时，它们需要排队，并且有许多不同的方法可以实现这一点。其中大多数方法涉及各种锁算法，以确保一次只有一个线程可以访问。MariaDB Server 对部分 InnoDB 事务日志使用的方法在较旧的平台上运行良好，但在较新的平台上，例如 Emerald Rapids，可以看到争用。不幸的是，对 Emerald Rapids 有效的加速修复可能会导致在较旧平台上变慢。
解决方案：innodb_log_spin_wait_delay
在英特尔提供了问题指引后，Marko 提出了一个新的 InnoDB 选项，称为“innodb_log_spin_wait_delay”。这个选项设置了每个线程在尝试获取锁之前的延迟。在较旧的英特尔架构（如 Haswell）上，设置此变量会导致速度稍慢，但在更新、更快的现代架构上，延迟的代价较低。这与“惊群问题”相对类似，毋庸置疑，多线程编程是一个复杂的主题。
作为 10.11 及更高版本中的一项功能提供
新的“innodb_log_spin_wait_delay”变量已包含在 MariaDB Server 10.11.8、11.0.6、11.1.5、11.2.4 和 11.4.2 版本中。可以使用 SET GLOBAL 命令进行设置，以便在运行时更改并根据您的配置进行测试。
最终结果是，使用 64 核 Emerald Rapids CPU，您可以在 HammerDB TPROC-C 基准测试中实现超过 100 万 NOPM（每分钟新订单）。这相当于在该测试中每分钟处理 230 万个存储过程事务。
这是运行了几分钟的测试结果，以显示其一致性。
HammerDB 的结论：性能提升 10%
虽然我没有精确的数字，但这个修复在这个平台上带来了大约 10% 的性能提升。
我与 Marko 聊了聊这个问题，他说他们最近还协助我们改进了用于 MDEV-33817（实现基于 AVX512BW 和 VPCLMULQDQ 的 CRC-32 算法）的 CRC-32 算法的性能。英特尔向他指出了一个关于利用较新架构中实现的现代向量指令的新算法的参考代码。Marko 说这使得 CRC-32C 计算性能提高了 3 倍，虽然这项操作本身并不昂贵，但点滴改进都有助于提升数据库的性能。
虽然我们自己的测试随着时间的推移很可能也会发现类似的问题，但 Marko 说，最了解自身架构的人更有可能更快地发现这些问题。
这就是为什么，正如我过去提到的，我们珍视与英特尔的合作关系。即使他们没有贡献很多直接的代码，他们提供的反馈也同样宝贵，甚至更宝贵。