作者 | 朱勇

1 实践背景介绍

某通信项目做万里开源数据库（GreatDB）性能测试时性能值未达到预期。测试工具为Sysbench，测试场景为读写场景，性能目标值为4000 TPS，实际测试值仅有3300 TPS，需要进行调优。

环境信息

服务器型号	TaiShan 2280
CPU配置	鲲鹏920 5250处理器（48C*2，2.6GHz）
内存配置	32G*32
操作系统	EulerOS/BClinux21.03

环境组网

数据库主要部署在虚拟机集群内（3节点），另有一台虚拟机作为压测机对数据库进行压测。

虚拟化平台使用FunshionCompute平台作为虚拟化底座，另有存储池作为虚拟机的存储资源，虚拟机的系统盘和数据盘都来自于存储池。

2 调优前数据

集群中三个节点都是64C128G虚拟机的测试数据：

线程数	QPS(/s)	TPS(/s)	95%响应时间(ms)	磁盘负载	CPU使用率
16	23443.77	1172.19	17.01	99%	10%
32	41928.88	2096.44	20.74	99%	20%
64	52505.00	2625.25	34.95	99%	25%
128	60786.10	3039.30	57.87	99%	30%
256	63421.21	3171.06	101.13	99%	33%
512	57675.81	2883.79	200.47	99%	35%

集群中三个节点都是32C64G虚拟机的测试数据：

线程数	QPS(/s)	TPS(/s)	95%响应时间(ms)	磁盘负载	CPU使用率
16	23387.45	1169.37	17.63	99%	25%±3%
32	36815.05	1840.75	25.28	99%	37%±3%
64	50339.42	2516.97	38.25	99%	50%±3%
128	59639.39	2981.97	61.08	99%	60%±3%
256	66055.79	3302.79	106.75	99%	64%±4%
512	55944.69	2797.23	227.40	99%	55%±4%

3 性能调优实践

从调优前的测试结果和部分指标来看，CPU不存在瓶颈，瓶颈主要在磁盘，但由于该测试方案是使用虚拟机进行测试的，CPU、磁盘、网络都是经过虚拟化的，因此虚拟化的损耗可能也是导致性能差的原因，另外数据库软件本身可能也有调优的可能。因此虚拟化层、存储层、数据库等层面都可能存在瓶颈，需要先缩小范围再进行进一步分析。可以采用以下方案来缩小范围：

1. 直接使用物理机安装GreatDB，测试物理机的性能，用物理机性能与虚拟机性能进行比较，看看虚拟化层的性能损耗比为多少，根据经验，通过虚拟化的CPU性能损耗在5%以内，如果性能损耗超过这个值，则虚拟化层需要进行调优。

2. 给虚拟机添加裸盘（磁盘直通方式）作为GreatDB数据盘进行测试，看看是否有性能提升，如果有性能提升较大，则说明磁盘层面确实存在瓶颈。

3. 如果虚拟化层和存储层都没有性能瓶颈，则数据库软件应用本身可能存在瓶颈，需要进行调优。

经过讨论后，先进行第2个方案的验证，添加裸盘后验证（虚拟机规格64C），256并发情况下可以测到3952 TPS，相对虚拟磁盘的3107 TPS提升了27%，说明存储层确实存在瓶颈，同时裸盘也是一个性能优化的方案，基本达到客户要求。

使用裸盘需要专门为虚拟机设置磁盘直通，对虚拟化平台来说增加了运维难度，后续通过调整虚拟磁盘的簇大小到32K，测试虚拟磁盘，256并发情况下可以测到3433 TPS。

继续对虚拟化层进行分析，由于物理机使用的是鲲鹏920 5250处理器，单片CPU核数为48，虚拟机使用64C规格大小时，内存访问始终会出现跨片的情况，而从客户给出的64C和32C的测试结果来看，虚拟机并不需要使用64C这么大的规格，使用48C规格虚拟机并进行CPU和内存绑定，可以避免内存出现跨片性能，从而提升CPU和内存的性能。

由于虚拟化使用FC平台，因此需要在FC平台上进行CPU配置更改，由于FC平台默认将宿主机的0-7 CPU核预留给系统使用，因此只能将虚拟机的核绑定到宿主机的CPU 48-95上。

关闭虚拟机后在FC平台上按照以下图片进行配置。

配置修改完成后，启动虚拟机，访问虚拟机所在的物理机，由于FC底层的虚拟化使用的是QEMU进程，因此可以执行numastat -s -p qemu命令查看物理机上的虚拟机内存分配情况：

从结果中可以看到，QEMU虚拟机的内存是分配在NUMA 2上的，而CPU是绑定在48-95上的，因此内存访问会出现跨NUMA的情况，但不会出现跨CPU的情况，内存访问情况比未做绑定前要好很多。

确认完成后进行测试，48C规格虚拟机、磁盘为裸盘的结果如下：

线程数	QPS(/s)	TPS(/s)	95%响应时间(ms)	磁盘负载	CPU使用率
64	61616.96	3080.85	29.72	99%	46%±3%
128	74421.07	3721.07	46.63	99%	54%±3%
256	85948.63	4297.43	77.19	99%	56%±4%
512	60032.23	3001.61	215.44	99%	56%±4%

从测结果来看，256并发情况下的TPS为4297，相比调整之前的3952提升了9%。

将裸盘替换为虚拟磁盘，256并发情况下的TPS为3980.51，也基本可以达标。

4 其他调优措施

因为时间和环境的关系，此次调优只调整了虚拟化的绑核和裸盘配置的方法，以下方法可能存在优化效果但未实施。

1. BIOS参数调整，抓取宿主机的BMC日志，可以看到BIOS中电源模式为省电模式，SMMU选项未开启，可以尝试在BIOS中调整这两个参数，看是否有优化效果。

2. GreatDB是用来替代MySQL数据库的，本质上可能是基于MySQL进行开发的，也许可以参考MySQL参数的优化来优化GreatDB数据库本身的性能。

3. 在极限情况下，还可以通过lto、pgo等方法编译GreatDB，尝试进一步优化数据库性能。

4. 宿主机内存配置调整为1 DPC。

5. 虚拟机使用内存大页进行内存分配，提高内存分配效率，根据历史经验，可能也会有些许的性能提升。

6. 宿主机使用了鲲鹏920 7260处理器，虚拟机规格调整为32C，CPU和内存绑定到同一个NUMA上，避免出现跨NUMA内存访问，进一步提升虚拟机性能。