1 方案概述

1.1 方案简介

本参考实践以鲲鹏服务器为计算底座，针对金仓数据库开展性能调优。主要设计思路为：一共部署2台服务器进行组网，其中1台为鲲鹏920新型号服务器，采用物理机部署的方式部署金仓数据库，另外1台服务器作为压测机，使用benchmarkSQL进行测试，以提升TPCC测试的tpmC值为目标进行性能优化。本实践虽基于鲲鹏920新型号服务器开展，但下文所述的调优思路与具体手段均属于鲲鹏平台通用特性，同样适用于其他鲲鹏系列服务器，具备广泛的参考价值。

1.2 调优思路

调优主要分为两部分，一部分是采用通用的服务器调优方法，以BIOS配置项调优、操作系统调优、磁盘IO调优、网络系统调优、文件系统调优共5个方向进行系统性能调优; 另一部分是根据金仓数据库的应用特点，对于金仓数据库参数进行调优，具体的调优手段参考章节4"调优参考实践"。

1.3 调优实施方式

为兼顾调优效率与深度，本实践提供两种并行的实施方式供用户选择：

方式一：一键自动调优（推荐) **。**为大幅简化调优流程，我们提供了自研的金仓数据库自动调优工具。该工具已将与鲲鹏硬件及金仓数据库相关的BIOS配置、操作系统参数、文件系统设置、数据库关键参数等数十项最佳实践集成在工具里。用户只需运行该工具，即可实现一键式、全栈式的性能配置优化，快速提升系统及数据库性能，适用于快速部署与通用性能提升场景。

具体使用说明参考"通算一体机性能综合调优参考实践（鲲鹏自动调优工具(KAOT)简介及使用说明)"：工具说明链接

方式二：分步手动调优。 如果您希望对每一项优化进行深度理解和控制，或需要根据业务负载进行专项调优，则可以遵循本参考实践后续章节提供的手动调优指南。该指南将详细拆解每一项优化措施的原理、操作命令、参数配置及验证方法，适合测试人员、现场实施人员和技术支持人员深度优化使用。

无论选择哪种路径，其优化的核心维度均围绕以下方面展开，具体实践细节详见第4章及后续章节。

1.4 应用场景

主要适用于金仓数据库在鲲鹏服务器上的性能调优，为金融、教育、医疗等解决方案场景提供数据库调优参考实践。

2 环境信息说明

2.1 软硬件配置

本参考实践的调优验证所涉及的详细软硬件信息如 表1 软件信息 和 表2 硬件信息。

表****1 软件信息

类别	软件名称	软件版本
虚拟机操作系统	Kylin Linux Advanced Server	V10 SP3-2403
数据库软件	金仓数据库	V8R6
测试工具	BenchmarkSQL	5.0

表****2 硬件信息

类别	硬件描述
CPU	鲲鹏 920新型号
内存	16*32GB
硬盘	2*3.7TB NVMe硬盘
网络	2*25GE网卡

2.2 环境组网介绍

一共部署2台服务器进行组网，其中1台为鲲鹏920新型号服务器，采用物理机部署的方式部署金仓数据库，另外1台服务器作为独立压测机，与数据库服务器通过高速网络互联。其上部署的BenchmarkSQL测试套件将模拟前端业务压力，向金仓数据库发起连续、并发的TPC-C标准负载，以检验其在真实业务场景下的tpmC吞吐量、响应时间及稳定性。

2.3 软件部署

2.3.1 金仓数据库部署

金仓数据库部署请参考kingbase金仓社区官网。

2.3.2 BenchmarkSQL部署

BenchmarkSQL部署参考BenchmarkSQL性能测试。

3 调优参考实践

3.1 调优手段总览

调优手段总览见下表1

表****1 调优手段总览

调优手段	作用
设置CPU高性能模式	通过将CPU频率固定在最高值获得最大化性能
开启SMT超线程	开启SMT超线程，每个物理核分为两个逻辑核，提升整机性能
关闭SMMU	数据库通常会使用大量的内存和IO资源，而SMMU会增加额外的开销和延迟，关闭后可以提升系统的性能
数据库进程绑核(可选)	将数据库进程绑定到固定CPU核心上，减少跨NUMA访存延迟，从而提升系统性能 【可选】该调优方法多用于低并发场景(并发数<150)，高并发场景(并发数>150)收益不明显，用户可以根据实际业务需要选择是否使能该调优项。
策略性抑制swap交换内存使用	减少数据库缓存交换到磁盘的情况，从而保证数据库的访问性能
选用性能更优的文件系统XFS(可选)	XFS是一种高性能的日志文件系统，其具有优秀的伸缩性与鲁棒性健，尤其擅长处理大文件，同时提供了平滑数据传输能力，相比默认的ext4文件系统性能更优 【可选】该调优项适用于新建数据库场景，用户可以根据实际业务需要选择是否使能该调优项。
数据、日志分盘	分盘后，日志盘专注处理顺序写，数据盘专注处理随机读写，从而减少磁盘竞争，从而提升并发吞吐能力。
磁盘IO调度策略调整	在固态硬盘场景下，使用none可以提升磁盘IO性能
网卡中断绑核	将处理网卡中断的CPU core设置在网卡所在的NUMA上，从而减少跨NUMA的内存访问所带来的额外开销，提升网络处理性能
数据库共享内存参数优化	可以将频繁访问的数据从缓慢的磁盘（微秒/毫秒级）移至高速的内存（纳秒级），从而提升数据库性能
数据库I/O相关参数优化	根据业务实际调整数据库配置参数，提升磁盘IO性能
数据库创表时不加外键(可选)	去除数据库外键可以减少数据修改时候额外校验带来的性能开销，达到降低CPU、I/O资源消耗，提升性能的效果 【可选】该调优方法多用于benchmark性能测试，在实际业务中仅作为优化思路进行参考，一般用于历史数据迁移或一次性初始化的场景，具体应用需要结合实际业务进行调整。
数据库填充因子修改(可选)	在插入和更新操作频繁的场景下，减小填充因子，可以减少由于索引页分裂而导致的I/O开销，从而提升插入、更新以及写入性能。 【可选】该调优方法多用于benchmark性能测试，在实际业务中仅作为优化思路进行参考，一般用于业务中更新极为频繁的核心表，具体应用需要结合实际业务进行调整。

3.2 操作系统调优

3.2.1 数据库进程绑核

该调优方法多用于低并发场景(并发数<150)，高并发场景(并发数>150)收益不明显，用户可以根据实际业务需要选择是否使能该调优项。

NUMA（非统一内存访问）是一种计算机内存架构，其中处理器对本地内存的访问速度比访问非本地的内存更快，跨NUMA访问会带来资源调度的消耗和访问延迟。因此可以将数据库进程绑定到固定CPU核心上，减少跨NUMA访存延迟，从而提升性能。

通常情况下，1颗CPU具有两个NUMA，绑核需要遵循的基本原则是：优先选择将数据库进程绑在同一个NUMA的CPU核心上，若数据库进程所需核心数超出一个NUMA的CPU核心数，则尽可能将数据库进程绑在同一颗CPU的核心上。

优化示例

以下示例以金仓数据库为例，非通用操作

步骤 1 进入kingbase.conf配置文件，该文件默认位置为/data/kingbase/es/v8/data/kingbase.conf

步骤 2 在kingbase.conf配置文件中添加参数 bindcpulist = ‘8-127’(此处填入需要绑核的CPU编号，尽可能考虑绑核的CPU都在同一个NUMA上，可以通过lscpu查看CPU以及所在的NUMA；实践中由于业务并发在100左右，因此使用0-127共128核两个NUMA进行绑核，且0-8一般用于系统内核操作，因此从8开始进行绑核；实际使用时可根据业务需要按需调整。)

3.2.2 文件系统调优

文件系统类型通常在服务器初始化、磁盘首次格式化时选定。对于已上线运行的生产系统，更换文件系统需要迁移数据，操作复杂、风险高、停机时间长，因此该调优项适用于新建数据库场景。用户可以根据实际业务需要选择是否使能该调优项。

XFS是一种高性能的日志文件系统，其具有优秀的伸缩性与鲁棒性健，尤其擅长处理大文件，同时提供了平滑数据传输能力。因此当条件允许的情况下，我们可以优先选择XFS文件系统。

在创建XFS文件系统时，推荐优先加大文件系统的block，例如默认blocksize为4KB, 推荐使用8KB, 可以进一步提升大文件操作场景的性能。

优化示例

步骤 1 格式化磁盘。假设我们要对nvme0n1进行格式化：

mkfs.xfs /dev/nvme0n1

步骤 2 指定blocksize，默认情况下为4KB(4096B)，我们假设在格式化时指定为变更为8192B：

mkfs.xfs /dev/nvme0n1-b size=8192

步骤 3 挂载到对应的目录

mount -t xfs /dev/nvme0n1 /目录名

3.3 数据库参数调优

3.3.1 数据库配置参数调优

共享内存参数优化：

shared_buffers参数用于设置数据库服务器使用的共享内存缓冲区的数量，主要用于缓存数据，可以将频繁访问的数据从缓慢的磁盘（微秒/毫秒级）移至高速的内存（纳秒级），从而提升数据库性能。该参数根据需求一般不能设置超过物理机整机内存总量的80%，但至少是20%。

数据库I/O相关参数优化：

在测试过程中分析出磁盘IO是性能瓶颈之一，因此调整数据库I/O相关参数进行磁盘IO性能优化

表****1 数据库配置参数调优总览

数据库配置参数名称	参数含义及应用	默认值	参考调优值
checkpoint_timeout	两个相邻检查点之间的时间间隔，用于刷数据到磁盘。 应用：根据系统写的负载设置, 一般不要太频繁，可以和后台写线程配置相关参数配合使用。	5min	20min
checkpoint_completion_target	表示checkpoint的完成时间要在两个checkpoint间隔时间的N%内完成。设置长一点，避免对性能测试的影响	0.5	0.9
bgwriter_delay	后台写线程的自动执行时间,后台写线程的作用是将 shared_buffer 里的脏页面写回到磁盘,减少 checkpoint 的压力。 应用：如果系统数据修改的压力一直很大,建议将该时间间隔设置小一些,以免积累的大量的脏页面到 checkpoint,使 checkpoint 时间过长(checkpoint 期间系统响应速度较慢)。	200ms	10ms
max_wal_size	检查点之间WAL日志允许增长的最大大小。 应用：设置较大的值（如300GB）可防止在写入高峰期因WAL增长过快而频繁触发检查点	1GB	300GB

创表时不加外键：

该调优方法多用于benchmark性能测试，在实际业务中仅作为优化思路进行参考，一般用于历史数据迁移或一次性初始化的场景，具体应用需要结合实际业务进行调整。

填充因子修改：

AL增长过快而频繁触发检查点 | 1GB | 300GB |

创表时不加外键：

该调优方法多用于benchmark性能测试，在实际业务中仅作为优化思路进行参考，一般用于历史数据迁移或一次性初始化的场景，具体应用需要结合实际业务进行调整。

填充因子修改：

该调优方法多用于benchmark性能测试，在实际业务中仅作为优化思路进行参考，一般用于业务中更新极为频繁的核心表，具体应用需要结合实际业务进行调整。