---
title: GreatDB性能调优-官方技术文章-鲲鹏社区
description: 基于鲲鹏平台优化GreatDB的读写场景性能。
keywords: GreatDB,性能调优,官方技术文章,鲲鹏社区,实践背景介绍,环境信息,环境组网,调优前数据
url: https://www.hikunpeng.com/developer/techArticles/20250911-3?envFlag=1
section: (其他)
---

# GreatDB性能调优-官方技术文章-鲲鹏社区

URL: https://www.hikunpeng.com/developer/techArticles/20250911-3?envFlag=1
描述: 基于鲲鹏平台优化GreatDB的读写场景性能。
关键词: GreatDB,性能调优,官方技术文章,鲲鹏社区,实践背景介绍,环境信息,环境组网,调优前数据

官方技术文章 [了解详情](https://www.hikunpeng.com/zh/developer/techArticles)

GreatDB性能调优

GreatDB性能调优

GreatDB

发表于 2025/09/11

0

作者 | 朱勇

## 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内存访问，进一步提升虚拟机性能。

本页内容