ARM架构下数据库迁移的中间件性能优化策略实现

欧阳美旺，陈晓军，鲁慧

（拓维信息系统股份有限公司）

1 引言

近年来，我国大力发展信创产业，基于ARM架构的企业级服务器产品，逐渐应用到政府、企业等各类平台。在技术层面，以精简指令集（RISC）为架构的ARM芯片体系具有一定的性能优势，但基于复杂指令集（CISC）的X86架构的原有应用与数据库迁移的安全、效率问题也引起了大量的关注。为了提高数据库迁移质量，快速实现平台各主营业务的全面贯通，确保内外部信息流的高效运转，尝试在对ARM架构及其生态体系分析的基础上，重点讨论基于ARM架构数据库迁移中应用中间件的性能优化问题，为提高数据库迁移的效率和质量提供切实可行的建议。

2 ARM架构生态体系

2.1 ARM与X86架构对比分析（见表1）

1）授权方式

ARM架构主要有指令集授权、内核授权和使用权授权三种方式，其中指令集授权灵活度最高，授权费用最贵。

2）版本更迭

自1985年ARM公司推出ARM v1，目前ARM架构已经升级到第8代，2019年ARM公司推出了最新的v9架构[1,2]。

3）性能更优

相比X86架构，ARM架构在功耗、发热、工作时长、数据安全等方面都具备明显优势。

2.2 ARM架构带来的适配挑战

ARM架构作为数据中心的后来者，在推动国产化自主可控项目上，面对诸多挑战。然而，由于X86架构在数据中心的市场份额和对开源社区长期的投入，目前各大开源社区的主要都是使用X86架构来进行开发、编译构建、集成验证、打包发布等开源开发流程。

对ARM用户来说想要直接使用通过基于X86架构开发流水线产出的软件包，常常面临着很多不确定因素和额外的工作量。因此，只有在开发流程中引入ARM架构开发流水线，端到端使用ARM架构，才能从源头解决适配问题。

3 中间件的性能优化

性能问题是多方面的，比如应用、系统软件（应用中间件、消息中间件、数据库等）、操作系统、硬件、网络，然而，如何诊断性能问题是出自应用中间件。本文从解读监控指标、指标优劣，及其关联入手，分析在应用中间件的性能优化的参数问题，并提出优化策略。

表1 ARM与X86架构对比表

3.1 技术路线

3.1.1 建立基准

在进行优化或者开始进行监视之前，首先要建立一个基准数据和优化目标。这个基准包括硬件配置、组网、测试模型、系统运行数据（CPU/内存/IO/网络吞吐/响应延时等）。性能调优是一个长期的过程。在优化工作的初期，很容易识别瓶颈并实施有效的优化措施，优化成果往往也很显著，但是越到后期优化的难度就越大，优化措施更难寻找，效果也将越来越弱。因此建议有一个合理的平衡点。

3.1.2 压力测试与监视瓶颈

使用峰值工作负载或专业的压力测试工具，对系统进行压力测试。使用一些性能监视工具观察系统状态。在压力测试期间，建议详细记录系统和程序的运行状态，精确的历史记录将更有助于分析瓶颈和确认优化措施是否有效。

3.1.3 确定瓶颈

压力测试和监视系统的目的是确定瓶颈。系统的瓶颈通常会在CPU过于繁忙、IO等待、网络等待等方面出现。需要注意的是，识别瓶颈是分析整个测试系统，包括测试工具、测试工具与被测系统之间的组网、网络带宽等。有很多“性能危机”的项目其实是由于测试工具、测试组网等这些很容易被忽视的环节所导致的，在性能优化时应该首先花一点时间排查这些环节。

3.1.4 实施优化

确定了瓶颈之后，接着应该对其进行优化。本文总结了笔者所在团队在项目中所遇到的常见系统瓶颈和优化措施。需要注意的是，系统调优的过程是在曲折中前进，并不是所有的优化措施都会起到正面效果，负优化也是经常遇到的。所以在准备好优化措施的同时，也应该准备好将优化措施回滚的操作指导。避免因为实施了一些不可逆的优化措施导致重新恢复环境而浪费大量的时间和精力。

3.1.5 确认优化效果

实施优化措施后，重新启动压力测试，准备好相关的工具监视系统，确认优化效果。产生负优化效果的措施要及时回滚，调整优化方案。如果有正优化效果，但未达到优化目标，则重复步骤2（3.1.2）“压力测试与监视瓶颈”，如达成优化目标，则需要将所有有效的优化措施和参数总结、归档，进入后续生产系统的版本发布准备等工作中。

3.2 案例分析

3.2.1 案例描述

Nginx的应用程序移植到ARM服务器上，发现业务吞吐量没有达到硬件预期，需要做相应调优。

3.2.2 问题原因

1）网卡配置

该应用场景下网络吞吐量大，网卡的配置能对性能提升起到很大的作用。

2）操作系统参数配置

在更换操作系统后，原来的一些调优措施需要重新定制。

3）应用程序

从X86切换到ARM之后，可以做一些代码层面、编译选项上的调优。

3.2.3 解决思路

1）网卡调优

① 中断绑核：中断亲和度描述为可以为特定中断提供响应的一组CPU，如果应用程序可以通过关联到相关的CPU，在相同的CPU上下文中处理接收到的数据包，则可以减少等待时间，提高CPU利用率。因此，可以将处理网卡中断的CPU core设置在网卡所在的NUMA上，从而减少跨NUMA的内存访问所带来的额外开销，提升网络处理性能。

在此案例中绑核拓扑如图1所示。

在服务器中搭载了4块1822网卡，每个网卡使用了4个端口，每个端口设置了6个队列。整机有96个CPU逻辑核，与这96个队列一一绑定。在应用程序上，也在nginx.conf中设置worker_processes为96。

② 使用网卡的TSO特性

TSO(TCP Segmentation Offload)将传出的TCP数据包的分片工作交给网卡来做，这样可以提高大量使用TCP协议传输数据的应用程序的性能。使用了TSO特性后，将为CPU减负，可有效降低发送端的CPU利用率。可以使用ethtool来使能TSO特性：

图1 中断绑核拓扑图

# /sbin/ethtool –K tso on

在这个案例中，启用了所有端口的TSO特性以实现更高的吞吐量。

③ 中断聚合

中断聚合通过合并多个接收到的数据包中断事件，将其一起发送到单个中断中，从而减少了网卡生成的中断数量。

● 增加中断聚合参数。

● 产生更少的中断。

● 降低CPU利用率。

● 增加响应延时。

● 提高整体吞吐量。

所以在这里增大了中断聚合相关参数。

修改方式：

使用ethtool -C $eth方法调整中断聚合参数。其中参数“$eth”为待调整配置的网卡设备名称，如eth0，eth1等。

# ethtool -C eth3 adaptive-rx off adaptivetx off rx-usecs N rx-frames N tx-usecs N txframes N

为了确保使用静态值，需禁用自适应调节，关闭Adaptive RX和Adaptive TX。

●rx-usecs：设置接收中断延时的时间。

●tx-usecs：设置发送中断延时的时间。

●rx-frames：产生中断之前接收的数据包数量。

●tx-frames：产生中断之前发送的数据包数量。

2）TCP协议参数调优

在测试过程中，通过perf trace工具捕捉到了sock:sock_exceed_buf_limit事件：

perf trace -e sock:sock_exceed_buf_limit -F 777

这表示内核TCP协议栈中的发送缓冲区已耗尽，发送缓冲区的内存大小成为阻塞应用程序性能的瓶颈。在这个案例中，设置成如下所示的值：

echo ‘4096 2097152 67108864’ > /proc/sys/net/ipv4/tcp_rmem

echo ‘4096 2097152 67108864’ > /proc/sys/net/ipv4/tcp_wmem

之后在测试过程中，没有再监控到sock:sock_exceed_buf_limit事件。

3）操作系统调优

使用perf工具来统计被测试进程的相关信息，发现上下文切换的频率很高。进一步使用perf 工具来监控被测进程，查看其中调度最频繁的部分。发现 timer_tick 在 ARM服务器中占了很高的调度时延。查看ARM服务器系统中的/proc/cmdline文件，发现其中包含了启动参数nohz = off，这表示在该系统中关闭了内核的nohz特性，这使得timer_tick切换变得更加频繁，增加了上下文切换的开销。为了解决该问题，在/boot/efi/EFI/euleros/grub.cfg中删除了该内核引导参数nohz = off。

4）应用程序调优

在搭载了ARM服务器上，可以在编译过程中指定处理器、架构相关的编译选项来进行优化。具体修改方式如下：

● 在Euler系统中使用HCC编译器，可以在CFLAGS和CPPFLAGS里面增加编译选项：

-mtune=tsv110 -march=armv8-a

在其他操作系统中，可以升级GCC版本到9.10，并在CFLAGS和CPPFLAGS里面增加编译选项：

-mtune=tsv110 -march=armv8-a

3.2.4 总结

应用中间件相关的性能监控与优化可以归类为6个字：判断、监控、优化。

1）如何判断性能问题是出自应用中间件？

从系统拓扑的角度：前端→中间件→应用→中间件→数据库的包抄当中，如果你发现其他都没有问题，那很可能就是中间件的问题了。

从系统层次的角度：应用→系统软件（中间件、数据库）→OS→硬件/网络这条线上，如果其他都没问题，那也得看看中间件了。

2）采用什么工具来监控中间件？

根据实际的应用部署场景，可以选择的监控范围有：中间件自身的监控、JVM的监控、应用的监控、分布式系统监视以及网络监视等。

监控的指标有：响应时间、Web应用程序相关指标、JDBC连接池、线程池、JVM虚拟机、会话数、垃圾回收GC、高速缓存、数据源语句缓存等。

3）中间件如何影响系统的性能指标（如吞吐量、响应时间、交易成功率）？

运行在中间件上的应用是委托“中间件”来处理“应用”与外界的一切联系，比如：

① 有请求进来，有多少个session来服务于请求。

② 应用需要读写数据库，数据库连接由应用中间件负责，并且还放置了连接池。

③ 应用需要多少内存，由中间件定制。

④ 应用需要做GC，由中间件定制。

4 数据库迁移适配策略

数据库系统迁移本身是一个复杂工程，异构数据库迁移相对同构数据库迁移技术难度更大，数据库系统迁移需要完善的规划方案和谨慎的实施操作，稍有不慎，就会导致迁移失败，甚至丢失重要数据。具体项目实施过程中，在数据库迁移流程与方法论的指导下，为解决迁移过程出现的问题，应具备详细的实施方案。

4.1 适配迁移流程整体设计

经整体分析，国产化替换异构数据库迁移存在很多不确定性因素与痛点，基于这些问题，现梳理一整套数据库迁移流程与方法论，需要说明的是，各阶段的顺序不是僵硬不变的，可按需在不同阶段之间向前和向后移动，这取决于每个阶段的结果和下一个阶段的具体任务，具体流程图可以参见表2。

表2 适配迁移流程设计

4.2 数据库与应用系统调研

数据库迁移过程中需考虑数据结构、数据类型、数据库性能、数据使用场景四个方面。数据库结构和数据类型是静态数据，可以通过语法、语义比对完成调研，数据库性能和数据使用场景是动态数据，与其对应的业务属性、数据库硬件资源、数据库自有能力、数据属性和应用系统属性直接相关。

应用的调研主要是发现应用和数据库之间的调用关系和调用方式，理清应用各个模块与数据库调用SQL的兼容特点，明确应用在各个模块转换的改造点。应用调整的内容取决于源、目标数据库架构切换的状态以及源数据库与目标数据库的兼容度。通过调用SQL详情实现改造点定位，即交互SQL点定位， 如应用系统采用成熟框架，可以在框架中直接完成修改，如在代码中直接嵌入SQL，若有成熟工具快速完成改造点定位和半自动化实现改造样本，将会极大方便改造工作。

5 结语

信创领域的政府信息化建设已从探索期，逐步进入大规模建设期，解决了系列适配技术问题，取得一定成果[3]。但处理数据库迁移适配问题，需要对中间件的技术进行深度优化，值得研究与关注。本文从解读监控指标、指标优劣，及其关联入手，分析在应用中间件的性能优化的参数问题，并提出优化策略。