当PolarDB数据库遇上倚天处理器，“双自研”助力性价比大幅提升

d_hero

发布于 2023-8-23 15:02

浏览

0收藏

1. 概述

PolarDB作为阿里云瑶池旗下的自研云原生数据库，基于存算分离的架构，具备一写多读、多活容灾、全球部署、HTAP等特性。上线五周年多以来，PolarDB已经广泛应用到了各行各业，有多篇papers发表在SIGMOD、VLDB、FAST等顶级会议上。相对应的，倚天710处理器作为阿里云自研的国产化芯片，基于新一代CIPU架构，实现了计算、存储、网络性能的数量级提升，有效应用于云原生、视频编解码、高性能计算、基于CPU的机器学习和游戏服务等场景。那么当PolarDB遇上了倚天处理器，当自研数据库碰上了自研芯片，又会释放出什么样的火花呢？

在开始全文前，我们回顾一下倚天处理器的独特优势。一方面，随着传统 x86 CPU的持续迭代，服务器和数据中心的功耗和成本在持续攀升，每千瓦芯片功耗在生命周期内带来上万美金的成本。另一方面，在云这类面向多租户的场景下，超线程（HT）架构的问题逐渐暴露出来，面对一些高密计算任务时很难满足业务需求，共享缓存与物理核的机制导致租户之间处理任务可能需要相互排队，导致性能大幅下降；或者互相干扰的情况导致性能波动。基于ARM架构的倚天处理器很好地解决这两个问题，独享物理核独享L1/L2 Cache，无超线程概念，在实现高性能（减少干扰）的同时实现了低功耗/低成本。

PolarDB 针对自研倚天芯片，从芯片到数据库内核全链路优化，性能相比优化前提升超50%。在 sysbench OLTP 读写混合场景下，PolarDB 倚天性能大幅领先同规格自建 MySQL 实例。

当PolarDB数据库遇上倚天处理器，“双自研”助力性价比大幅提升-鸿蒙开发者社区

2. 全路径性能优化

为了充分发挥出自研数据库PolarDB在自研芯片倚天上的性能，PolarDB团队从芯片侧到数据库内核做了全路径的优化。用户业务和应用从x86架构数据库向倚天ECS架构数据库迁移的过程中，业务代码改造量是零，成功实现无缝迁移：用户只需要把数据库的连接地址，从x86架构改成PolarDB On倚天ECS的地址即可。

2.1 全栈优化

针对倚天处理器这一全新的ARM体系，PolarDB从芯片到操作系统，进行了全栈的深度优化：

● 芯片：针对数据库应用场景，调整处理器预取策略。数据库的内存访问与很多负载不同，访问模式更加随机，不适合通用的数据预取策略。在数据库场景下，过于激进的数据预取可能无法提高缓存命中率，反而会增加内存带宽的使用，并且在缓存中填充无效的数据。调整预取策略，为缓存设置合理的指令预留，给 PolarDB 倚天带来显著的性能收益。

● 网络：网络收发产生频繁的中断，导致系统态和用户态的切换。数据库对网络吞吐要求低，适当减少网卡队列的数量可以起到聚合硬件中断的效果。进一步把中断绑定到固定的核心上，可以减少状态切换造成的影响，提高数据库整体的运行效率。

● 操作系统：推进操作系统版本，使用新OS内核，充分利用新版本操作系统对倚天处理器的支持和优化。采用代码大页优化，将数据库代码段通过透明大页映射，减少 iTLB 的使用，从而减少整个系统中 TLB 资源的争抢，显著降低 iTLB miss，提升性能。此外，对数据库场景调整了CFS调度器参数，使系统能在高压力场景下合理调度数据库的线程，保证处理器资源的充分利用。

● 编译器：启用 LSE 指令拓展，使用原生的 CAS 等指令实现数据库的原子操作，优化了加锁、解锁等操作的性能，极大提高了数据库高并发场景下的性能，在高并发写场景可提供数倍的性能提升。使用更新版本的 GCC 和 glibc，充分利用新版本编译器和标准库对 arm 架构的支持和优化。启用 PGO 优化技术，使用运行时的剖析信息指导编译优化过程，针对典型的数据库场景优化，使生成的二进制在大多数场景下拥有更好的性能。启用了链接时优化技术，扩展了编译器过程间分析的范围，全局优化数据库代码。

2.2 数据库内核优化

为了获取良好的性能，PolarDB在内核层面做了深度优化。其中，尤其PolarDB在多线程扩展性方面的优化，相较于传统MySQL，在倚天等多核处理器上发挥出了明显的优势：

● 针对计算存储分离架构的全路径优化：针对分布式存储和本地存储的差异性，实现了Partition Redo / Early Lock Release / Parallel Redo Apply / Lock-Less Flush / Multi-Queue AIO等全路径优化，显著降低了IO延迟对数据库性能的影响，提升了多核场景下的性能，感兴趣的读者可以查阅我们发表在VLDB'22的文章[1]；

● 高性能索引 PolarIndex：实现了Btree在做SMO操作时不持有Index锁，从而支持多个SMO操作并发执行，明显提升了高并发更新/插入场景下的性能；

● 弹性并行查询 Elastic Parallel Query：针对云上用户实例CPU资源利用率较低、使用不均衡的特征，充分挖掘集群中多核CPU的并行处理能力，明显提升了单条大查询的处理效率；

● 并行DDL：针对大表DDL慢的问题，将DDL全过程拆分成多个子任务，利用多核能力并行加速DDL的执行，线性降低DDL的延迟；

● 事务系统优化：优化了高并发场景下活跃事务列表拷贝的瓶颈，明显提升了多核场景下的性能；

● 原子操作/内存屏障调优：相比于X86架构，ARM架构场景下是weak memory order，PolarDB内核团队优化了原子操作和相关屏障级别，降低并发场景下的系统性能损耗；

● 新指令支持：使用 arm 架构原生 CRC32 指令，硬件加速内核 CRC 计算，显著降低计算校验码的热点；

● 线程优先级/内核参数调优：针对倚天处理器的具体性能特征，调整了内核IO线程的优先级，细粒度调优了内核各类参数。

3. 测试结果

3.1 测试结果说明

通过对 sysbench OLTP 读写、只读和只写三种场景和 IO bound 、CPU bound 两种数据量下的压测，在每种场景和每个连接数下取压测结果QPS平均值统计，得到结果：

● 读写场景：CPU bound 测试中，PolarDB 倚天实例性能超过自建实例90%；IO bound 测试中，PolarDB 倚天实例性能超过自建实例80%；

● 只读场景：CPU bound 测试中，PolarDB 倚天实例性能超过自建实例110%；IO bound 测试中，PolarDB 倚天实例性能超过自建实例100%；

● 只写场景：CPU bound 测试中，PolarDB 倚天实例性能超过自建实例100%；IO bound 测试中，PolarDB 倚天实例性能超过自建实例50%。

3.2 测试环境

▶︎ 实例规格

当PolarDB数据库遇上倚天处理器，“双自研”助力性价比大幅提升-鸿蒙开发者社区

▶︎ 测试参数

sysbench 1.0.20
CPU bound：10表 10000000行，约 24G 数据
IO bound：10表 40000000行，约 100G 数据
--rand-type=uniform

3.3 测试方法

# 准备数据
sysbench --db-driver=mysql --mysql-host=XXX --mysql-port=XXX --mysql-user=XXX --mysql-password=XXX --mysql-db=sbtest --table_size=40000000 --tables=10 --threads={1~512} oltp_read_write prepare

# 运行workload
# OLTP读写混合
sysbench --db-driver=mysql --mysql-host=XXX --mysql-port=XXX --mysql-user=XXX --mysql-password=XXX --mysql-db=sbtest --table_size=40000000 --rand-type=uniform --tables=10 --time=300 --threads={1~512} --report-interval=20 oltp_read_write run

# OLTP只读场景
sysbench --db-driver=mysql --mysql-host=XXX --mysql-port=XXX --mysql-user=XXX --mysql-password=XXX --mysql-db=sbtest --table_size=40000000 --rand-type=uniform --tables=10 --time=300 --threads={1~512} --report-interval=20 oltp_read_only run

# OLTP只写场景
sysbench --db-driver=mysql --mysql-host=XXX --mysql-port=XXX --mysql-user=XXX --mysql-password=XXX --mysql-db=sbtest --table_size=40000000 --rand-type=uniform --tables=10 --time=300 --threads={1~512} --report-interval=20 oltp_write_only run

# 清理数据
sysbench --db-driver=mysql --mysql-host=XXX --mysql-port=XXX --mysql-user=XXX --mysql-password=XXX --mysql-db=sbtest --table_size=40000000 --tables=10 --time=300 --threads={1~512} oltp_read_write/oltp_read_only/oltp_write_only cleanup