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

最近接到技能支持部分的告急，说是有个客户在测试我司数据库某个版本的进程中发显着显的机能题目，但愿我们可以或许资助尽快找到缘故起因，并提供办理方案。颠末观测研究，最终确定是由CPU cache line “false sharing” 引起的题目。

鉴于网上相同的文章较少，而且这种题目每每在代码中较量潜伏，较难等闲发明，以是在这里做个分享。假如可巧对其他做相同事变的人有所开导，本人将很是兴奋。

配景先容

这个客户多年来一向行使我司的数据库，今朝规划进级到更高版本，但在对数据压缩成果的测试中发明，在某种环境下，在压缩过的数据表上做全表扫描(table scan)所耗费的时刻会跟着并发的全表扫描使命数的增多而明显增进，而未经压缩过的数据表则没有这种征象。

数据压缩是我们团队多年前开拓的一个成果，之前做过大量的代码优化，机能相比拟力不变，其实不该该会有这样的题目，这也因此引起了我极大的乐趣。

相识数据库的人都知道，影响数据库的机能的身分较多，好比处事器的硬件设置，数据库的参数配置，数据的磁盘漫衍等，虽然，也不解除数据库自身代码的题目，不太轻易一下定位到详细的缘故起因。一样平常环境下，假如能通过数据库调优办理题目，就没须要耗费大量时刻去观测数据库源代码，以是，在整个题目的观测研究进程中，我的原则是，先易后难，斗胆意料，逐项解除。

观测思绪

客户属于金融行业，对数据安详有严酷的划定，基础不行能让我会见他们的数据库体系去做说明，独一的要领就是，先当地重现题目，然后调试。当地重现是个耗损体力和想象力的进程，索性颠末许多次的雷同和实行，终于重现了相同的征象。

1)数据库行使题目 vs 数据库代码题目

在一开始确定这个题目长短常须要的，它将抉择接下来所耗费的时刻和精神的巨细。

跟客户做了些雷同，发明他们对数据库没有较量深入的相识，以是，起首猜疑的是，有没有也许他们的数据库体系中的某些设置参数配置不公道，从而影响机能呢?

很快拿到了客户的数据库设置文件，一一说明，并团结当地尝试，发明并无明明的题目，独一的一个题目是，某个跟数据压缩统计信息相干的设置参数打开了，这个参数首要是在说明题目的时辰行使的，出产情形是不提议打开的，当即封锁了这个设置参数，在当地情形中从头测试了一下，发明机能有些改进。

当即提议客户也做同样的实行，很快获得反馈，机能有所晋升，但还未到达他们的预期。

看样子工作没那么简朴，接下来开始倾向于以为，也许数据库代码那边出了题目。

2)锁竞争 (lock contention)

在支持高并发的数据库体系中，为了同步差异使命对一些要害资源的会见，行使锁是一种常见的方法，如spinlock，mutex等，可是，一旦产生严峻的锁竞争，将会极大影响数据库体系的机能。固然近些年lockless的呼声很高，可是一个数据库体系要完全做到lockless照旧较难的，一样平常的计策是，对某些要害的，轻易引起竞争的布局可能模块回收lockless的方法。以是，搜查锁竞争是下一步的重点。

我司的这款数据库固然环球市场份额不大，但也是深耕该行业的老品牌，在海外的金融规模口碑载道，在无数次市场检讨的进程中，为了更好地说明各类题目，工程师们在体系中插手了要害信息的统计成果。

通过说明一些体系要害资源的统计信息，并未发显着显的锁竞争，可能资源竞争，尤其是跟数据压缩相干的，以是，这个也许的缘故起因解除去。

（编辑：湖南网）

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