CPU时间都去哪了：一步步定位数据库代码中的性能极限

最近接到技术支持部门的求助，说是有个客户在测试我司数据库某个版本的过程中发现明显的性能问题，希望我们能够帮忙尽快找到原因，并提供解决方案。经过调查研究，最终确定是由CPU cache line “false sharing” 引起的问题。

鉴于网上类似的文章较少，并且这种问题往往在代码中比较隐蔽，较难轻易发现，所以在这里做个分享。如果碰巧对其他做类似工作的人有所启发，本人将非常高兴。

背景介绍

这个客户多年来一直使用我司的数据库，目前打算升级到更高版本，但在对数据压缩功能的测试中发现，在某种情况下，在压缩过的数据表上做全表扫描(table scan)所花费的时间会随着并发的全表扫描任务数的增多而显著增加，而未经压缩过的数据表则没有这种现象。

数据压缩是我们团队多年前开发的一个功能，之前做过大量的代码优化，性能相对比较稳定，实在不应该会有这样的问题，这也因此引起了我极大的兴趣。

了解数据库的人都知道，影响数据库的性能的因素较多，比如服务器的硬件配置，数据库的参数设置，数据的磁盘分布等，当然，也不排除数据库自身代码的问题，不太容易一下定位到具体的原因。一般情况下，如果能通过数据库调优解决问题，就没必要花费大量时间去调查数据库源代码，所以，在整个问题的调查研究过程中，我的原则是，先易后难，大胆猜想，逐项排除。

调查思路

客户属于金融行业，对数据安全有严格的规定，根本不可能让我访问他们的数据库系统去做分析，唯一的方法就是，先本地重现问题，然后调试。本地重现是个消耗体力和想象力的过程，索性经过很多次的沟通和尝试，终于重现了类似的现象。

1)数据库使用问题 vs 数据库代码问题

在一开始确定这个问题是非常必要的，它将决定接下来所花费的时间和精力的大小。

跟客户做了些沟通，发现他们对数据库没有比较深入的了解，所以，首先怀疑的是，有没有可能他们的数据库系统中的某些配置参数设置不合理，从而影响性能呢?

很快拿到了客户的数据库配置文件，逐一分析，并结合本地实验，发现并无明显的问题，唯一的一个问题是，某个跟数据压缩统计信息相关的配置参数打开了，这个参数主要是在分析问题的时候使用的，生产环境是不建议打开的，立即关闭了这个配置参数，在本地环境中重新测试了一下，发现性能有些改善。

立即建议客户也做同样的尝试，很快得到反馈，性能有所提升，但还未达到他们的预期。

看样子事情没那么简单，接下来开始倾向于认为，可能数据库代码哪里出了问题。

2)锁竞争 (lock contention)

在支持高并发的数据库系统中，为了同步不同任务对一些关键资源的访问，使用锁是一种常见的方式，如spinlock，mutex等，但是，一旦发生严重的锁竞争，将会极大影响数据库系统的性能。虽然近些年lockless的呼声很高，但是一个数据库系统要完全做到lockless还是较难的，一般的策略是，对某些关键的，容易引起竞争的结构或者模块采用lockless的方式。所以，检查锁竞争是下一步的重点。

我司的这款数据库虽然全球市场份额不大，但也是深耕该行业的老品牌，在国外的金融领域有口皆碑，在无数次市场检验的过程中，为了更好地分析各种问题，工程师们在系统中加入了关键信息的统计功能。

通过分析一些系统关键资源的统计信息，并未发现明显的锁竞争，或者资源竞争，尤其是跟数据压缩相关的，所以，这个可能的原因排除掉。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!