TiDB 多 Socket 服务器性能扩展问题分析

作者： Hacker_URrvEGHH 原文来源：https://tidb.net/blog/039eacc4

【是否原创】是

【首发渠道】TiDB 社区

【首发渠道链接】其他平台首发请附上对应链接

【目录】

【正文】

在之前一篇TiDB 性能优化实践中提到，TiDB 的性能可以通过绑定 NUMA 的方式提升性能。同时，通过分析，发现 Go 运行时中的 runtime.heapBitsSetType 函数可能是影响 TiDB 在多 Socket 服务器环境提升性能的主要原因。在这一篇，我们将使用 Perf c2c 工具进行进一步的分析。

按照我们过去的经验，CPU Cache line 上的读写访问冲突，特别是Cache line 假共享问题，是许多应用程序在多核尤其是多 Socket 服务器上性能扩展不佳的一个典型原因。针对这类问题，perf c2c 工具可以帮助进行分析。

使用 perf c2c 工具，我们首先获得一个出现 HITM 的地址从多到少的列表，是下面这样子滴：

然后，我们具体分析列表中的第一行数据，即地址 0x57ae900 所在 cache line 上的读写访问冲突，如下图所示。可以看出大约 90% 的 Remote HITM 都和函数 runtime.heapBitsSetType 有关。而导致它出现 HITM 原因，是由于函数 runtime.(*mspan).sweep、runtime.sweepone 和函数 runtime.(*mheap).reclaim 对该 cache line 的写操作造成的。而从 CL off 上看，读、写操作访问的偏移地址并不一样，说明这很有可能是一个 cache line 的假共享访问问题。那么通过改变相关的数据定义，使热点的读、写数据分别放在两个 cache line 上，是有可能解决这个问题的。

遗憾的是，perf 工具对 go 程序的支持还不完善，不能像对 c 语言程序那样得到访问该 cache line 的具体代码位置。我们对 go 语言的只是也很有限。不知道这个问题是 Go 程序的一个已知共有问题，还是和 TiDB 的某种具体实现有关。如果社区里的同学知道如何通过代码地址关联到 go 源代码的位置，欢迎在评论区留言，一起来分析和解决这个问题！