我们在做ARM服务器选型和性能摸底的时候最常被问到的一个问题就是这台机器到底能扛多大的并发单核算力跟x86比到底差多少内存带宽够不够磁盘IO会不会成为瓶颈这些问题的答案不能靠拍脑袋得靠基准测试工具给出一个相对可量化的数据。而在Linux环境下sysbench几乎是做这类摸底测试绕不开的工具。这篇文章就围绕CentOS 7在aarch64ARM 64位平台上的sysbench安装以及CPU、内存、IO三大项的测试方法展开。我会把我在鲲鹏、飞腾这些ARM服务器上实测时用到的命令、参数、判断逻辑和踩过的坑都写出来。不管你是刚接触ARM服务器还是已经在做迁移评估这篇文章都能让你少走不少弯路。1. ARM平台做性能摸底为什么首选sysbench先聊一个基础问题ARM服务器上能用的压测工具不少像stress、stress-ng、lmbench、iperf、fio各有各的侧重为什么sysbench做第一轮摸底最合适原因有三个。sysbench自带CPU、内存、文件IO、线程、互斥锁、甚至数据库OLTP的测试模块一套工具就能覆盖我上面提到的绝大多数问题。做第一轮评估的时候我不想在每台机器上装五六个不同的工具sysbench一个就够撑起前期的初筛工作。它的输出格式非常稳定而且核心指标就是每秒事件数events per second也就是每秒能完成多少次指定的计算任务。这个数字在进行横向对比时非常直观不像某些工具输出一堆拗口的专业术语还得自己去理解每个指标的含义。第三个原因也很实际sysbench的依赖非常少在CentOS 7的aarch64源里直接就有编译好的二进制包安装成本低这对批量处理多台服务器来说很重要。如果是在内网离线环境把RPM包拷进去离线安装也不复杂后面我会写具体的操作。一个常见的误区是拿sysbench去模拟真实业务。它在设计上是一个“微基准测试”工具测的是硬件的极限吞吐和计算能力而不是你业务代码的真实表现。真实业务的性能还跟应用架构、中间件配置、网络拓扑等一大堆因素相关所以sysbench给出的数据适合用来做“这台机器硬件的底子怎么样”的判断至于“业务跑起来会不会卡”需要压测工具业务脚本配合才能回答。顺带提醒一下在ARM平台上做测试首先要确认你装的是aarch64版本的sysbench。我见过有人在aarch64的机器上用yum装了一个x86_64的RPM包结果一执行就报“Exec format error”或者“cannot execute binary file”看着就像工具坏了其实是架构不匹配。2. 安装前先看清家底架构确认与系统环境检查在敲任何安装命令之前我建议你先花两分钟把机器的底细摸清楚。别嫌这一步多余我遇到太多人上来就装装完发现装错包或者系统版本太老跟源对不上浪费时间。检查架构和系统版本用下面这几条命令uname -m cat /etc/redhat-release lscpu free -h df -huname -m会输出aarch64确认这台机器确实是ARM 64位架构。如果这里输出的是x86_64那你后面就不该按ARM的思路来装包。cat /etc/redhat-release确认系统版本。CentOS 7的aarch64支持在生命周期内是正常的但要注意不同小版本比如7.6和7.9对软件源里的包版本会有影响。lscpu能直接看到CPU型号、核心数、线程数、频率等信息后面设计测试参数时要用到。free -h看内存大小决定内存测试要用多大的总容量。df -h看磁盘剩余空间文件IO测试会生成临时文件空间不够测到一半会失败。以我常用的那台鲲鹏920机器为例lscpu输出里能看到CPU(s): 64、Model name: Kunpeng 920之类的信息确认了核心规模之后我才会去设计后面的多核CPU测试线程数。环境这块容易踩的一个坑是CentOS 7的aarch64最小化安装可能没有装epel-release而sysbench在CentOS 7的base源里是没有的必须要先装EPELExtra Packages for Enterprise Linux源才能用yum装到sysbench。有次我在一台刚交付的飞腾FT-2000/64机器上操作直接yum install sysbench结果提示No package sysbench available当时第一反应是源没配好后来一看EPEL确实没装。3. sysbench安装全记录yum最快源码兜底3.1 方式一EPEL源 yum安装推荐如果你在的机器能正常访问外网或者内网有同步好的EPEL源这个问题就很简单。依次执行# 安装EPEL源CentOS 7 aarch64对应的RPM包名 yum install -y https://mirrors.aliyun.com/epel/epel-release-latest-7.noarch.rpm # 更新源缓存 yum makecache # 安装sysbench yum install -y sysbench # 验证安装 sysbench --version这里需要说明一下为什么用阿里云的镜像地址。CentOS 7的官方源地址在2024年后已经停止维护如果你直接去访问默认的mirror.centos.org大概率会失败或者只能拿到一个静态的快照版本速度也不行。国内用阿里云、清华或者腾讯的镜像不管是连通性还是速度都好很多。当然如果你所在的内网环境有自己的yum源仓库把上面地址换成内网地址也是一样的逻辑。安装完成后sysbench --version会输出类似sysbench 1.0.20的版本号。我建议用1.0.x这个系列的版本0.4.12那个老版本虽然也还能用但参数写法和输出格式跟1.0差别很大网上的教程大多以1.0为准你装了老版本再去对照会很痛苦。3.2 方式二源码编译安装离线环境兜底没有外网、内网又没有RPM包的时候编译安装是唯一的出路。sysbench的源码编译依赖automake、libtool、make、gcc这些基础工具还有mysql-devel如果你要用OLTP模块的话只测CPU、内存、IO可以不装这个依赖。# 安装编译工具链 yum install -y gcc make automake libtool # 下载源码包在能联网的机器上提前下载好再拷进内网 wget https://github.com/akopytov/sysbench/archive/1.0.20.tar.gz tar -xzf 1.0.20.tar.gz cd sysbench-1.0.20 # 生成configure脚本 ./autogen.sh # 配置、编译、安装 ./configure --without-mysql make -j$(nproc) make install./configure --without-mysql的意思是跳过MySQL依赖检查因为这里只需要CPU、内存和IO测试模块。如果是做数据库压测那就要先装好mysql客户端开发库去掉这个参数重新配置。源码编译在ARM平台上比你想象的要简单因为sysbench本身对架构没有特殊的汇编优化代码纯C语言写的aarch64的gcc编译器直接就能搞定。我唯一遇到过的编译问题是在某些老版本gcc4.8.5下编译时出现告警但还没碰到过因为架构导致编译失败的情况。3.3 方式三RPM包离线安装如果你有另一台同架构、同系统版本的机器可以联网yumdownloader可以把RPM包及相关依赖全部拉下来然后拷到离线机器上安装。这是内网环境比较舒服的姿势。# 在有网的aarch64 CentOS7机器上执行 yum install -y yum-utils mkdir -p /root/sysbench-rpms cd /root/sysbench-rpms yumdownloader --resolve sysbench # 把整个目录拷到离线机器然后执行 rpm -Uvh *.rpm需要优先说明的是yumdownloader --resolve会把sysbench以及所有依赖包都下载下来但不包含系统的核心依赖所以离线机器上如果连libtool这类基础库都没有可能还是要先处理基础库。好在CentOS 7 aarch64最小化安装已经带了大多数运行库rpm装sysbench通常不会缺依赖。4. CPU基准测试单核、多核到底怎么压才算数4.1 CPU测试参数设计--cpu-max-prime是关键sysbench的CPU测试逻辑其实是让CPU去计算指定范围内的最大质数。每次计算任务都从一个起始数开始一直找质数找到--cpu-max-prime设定的上限。这个值设得越大单次任务耗时越长测试结果越能体现CPU的持续计算能力设得小单次任务瞬间就完成测试的颗粒度太粗难以区分不同CPU的差异。我的习惯是把--cpu-max-prime设为10000到20000之间。以10000为例每次find_prime的计算量适中既不会因为太大导致单次任务耗时过长、拉长整体测试时间也不会因为太小让结果被系统调度噪声干扰。一个容易被忽视的点是如果--cpu-max-prime设得太小比如只有100试试看结果几乎所有CPU跑出来的每秒事件数都极高几十万上百万这时候数据就失去了区分度。就像用一个精度为1克的秤去称两颗差不多重的鸡蛋看不出差别来。设到20000的时候不同代际、不同频率的CPU之间的差异就能拉开。完整的CPU单核测试命令sysbench cpu --cpu-max-prime20000 --threads1 --time30 run--time30表示跑30秒就停止。我不建议把单次测试时间设太短10秒以内的测试很容易被瞬时负载干扰数据跳动很大30秒是个比较能说明问题的平衡点。执行完会看到类似这样的输出CPU speed: events per second: 452.63这个events per second每秒事件数就是核心指标。事件数除以线程数就是单线程每秒能完成的质数计算任务数。4.2 多核测试直接跑满所有核心看整体吞吐多核测试的思路有两种一种是测试整机的聚合性能把线程数设为跟物理核心数一致看总吞吐另一种是测试超线程/多核调度是否正常线程数设为核心数的两倍看会不会出现明显的性能下降或者调度不均。以一台64核的鲲鹏920机器为例我会先测一次64线程的# 物理核心数可以通过 lscpu 的 Core(s) per socket 和 Socket(s) 计算 sysbench cpu --cpu-max-prime20000 --threads64 --time30 run64线程的结果如果每秒事件数约等于单核结果乘以64说明CPU的多核扩展性非常线性调度没有明显瓶颈。实际情况中因为内存带宽、CPU频率调度等影响多核跑出来的每秒事件数稍微低于单核值乘以核心数这是正常的差别在10%以内都算健康。再测一次128线程如果开了超线程sysbench cpu --cpu-max-prime20000 --threads128 --time30 run128线程如果跟64线程相比没有明显提升甚至下降那就说明超线程在这个负载下没有带来收益后续做业务容量规划时就不能盲目按照“逻辑核数”去预估并发能力。4.3 CPU结果的解读标准拿到结果后怎么判断这台机器的算力水平呢我的经验是先跟同型号机器的公开评测数据对比看看有没有明显偏离。再跟手上的x86机器对比用同样的参数跑一遍记录单核和全核的events per second计算两者的比值这就是相对性能差异。重点关注单核数据因为多核数据容易受核心数量影响单核数据更能体现架构IPC每时钟周期指令数和频率的真实水平。我曾经拿一台2.6GHz的鲲鹏920跟一台2.5GHz的Intel Silver 4210做过对比单核events per second大约低了30%但多核由于核心数量优势反而更高。这说明在单线程密集型业务上ARM服务器确实吃亏但在高并发、多线程场景下可以靠核心数量弥补。5. 内存基准测试带宽、延迟、分配你测的到底是哪一个维度5.1 sysbench内存测试的原理sysbench内存模块的逻辑比CPU更复杂一点。它做的事情是在内存中连续分配一块区域然后按照指定的block size进行读写操作。默认情况下--memory-operwrite表示写操作每次写入一个block大小的数据统计单位时间内完成了多少次操作。这里有个非常关键的概念sysbench的内存测试反映的是内存带宽和内存控制器性能而不是内存延迟。你想测延迟得用lmbench这类专门的latency工具sysbench测不了这个。很多新手拿着sysbench的内存数据去推断业务延迟表现这是完全错误的方向。内存测试还分两种模式顺序访问和随机访问。默认是顺序访问--memory-access-modeseq随机访问可以加--memory-access-modernd。顺序访问更贴近内存带宽测试场景随机访问则更贴近真实业务中指针跳转、哈希表查找这类访问模式。5.2 内存测试的参数block size怎么选--memory-block-size是决定测试效果的重要参数。block size越小操作次数越多CPU参与度也越高测出来的结果越偏向“内存控制器CPU缓存交互”的综合表现block size越大单次操作传输的数据量越大测出来的结果越接近“纯内存带宽”。我的做法是分两档测试# 小block测试内存控制器与缓存的协同能力 sysbench memory --memory-block-size1K --memory-total-size10G --threads1 run # 大block测试纯内存带宽 sysbench memory --memory-block-size1M --memory-total-size10G --threads1 run--memory-total-size10G表示整个测试过程中总共传输10GB数据也可以用--time30指定测试时长我习惯用--memory-total-size指定总数据量这样得到的MiB/sec吞吐量更直观。注意1MB的block size跟L3缓存之间会有交互。如果CPU的L3是32MB那么1MB的block是小于L3的测出来的带宽可能被cache加速如果block size大于LLC数据才会真正落到内存控制器。想测“真实内存带宽”block size建议设成L3缓存大小的2倍以上比如L3是32MB就设--memory-block-size64M。5.3 用多线程把内存带宽拉满单线程的内存测试往往跑不满内存带宽毕竟一个核心能发出的内存请求数量有限。要摸清内存带宽的上限得把线程数加上去sysbench memory --memory-block-size1M --memory-total-size64G --threads$(nproc) run这里--memory-total-size64G需要根据机器实际内存来调整原则是总传输量除以线程数后每个线程要传输的数据量不能太小否则还没跑起来就结束了。通常每个线程分到1GB以上的传输量会比较稳定。多线程跑内存测试时我发现两个问题需要留意第一个是NUMA效应。多路ARM服务器比如2路鲲鹏920是典型的NUMA架构每个CPU有自己的内存控制器。如果线程被调度到Node 0但内存分配在Node 1跨节点访问的带宽会明显下降。所以测试前最好用numactl --hardware看清节点拓扑测试时分别绑定Node 0和Node 1或者用numactl --interleaveall做交织访问这样才能得到一个相对稳定的参考值。第二个是swap干扰。如果机器内存不够大而--memory-total-size设得很大数据会被换到swap分区这时候测出来根本不是内存性能而是磁盘性能。测之前用free -h确认可用内存充足。5.4 内存测试结果怎么判断好坏sysbench内存测试的输出核心指标是MiB/sec每秒传输多少MiB。举例来说Total operations: 10240 (1023.45 per second) 10240.00 MiB transferred (1023.45 MiB/sec)看到1023.45 MiB/sec就知道这台机器的顺序写带宽大约1GiB/s。如果是多线程跑满的情况下值一般会更高DDR4平台常见在10GiB/s到20GiB/s之间。判断好坏我的标准很简单先看多线程能不能把带宽拉起来如果多线程结果跟单线程差不多说明内存控制器很可能已经到瓶颈了再对比同平台其他机器的数据看有没有因为BIOS设置比如内存频率跑在2133而不是3200导致带宽差了一大截。我记得有一次排查一台ARM服务器性能不达标的问题最后发现是内存被BIOS默认设成了降频状态用sysbench一跑就露馅了。6. 文件IO基准测试先想清楚你要模拟什么负载6.1 文件IO测试的设计思路文件IO测试是sysbench里最容易被误用的一块但它恰恰又非常重要——大多数业务系统的瓶颈不在CPU而在磁盘。sysbench的fileio模块会预创建一个或多个测试文件然后按照指定的模式进行读写。测试前必须执行prepare阶段# 先创建测试文件总大小8GB32个文件 sysbench fileio --file-total-size8G --file-num32 prepareprepare会在当前目录下生成测试文件。这里有个要注意的细节测试文件生成在哪个目录测的就是哪个目录所在文件系统的性能。所以要么先进到目标数据目录再跑比如cd /data要么用--file-extra-flagsdirect配合绝对路径来控制在指定目录生成。如果直接在根目录跑测的是系统盘那数据就不代表数据盘的性能。文件IO的测试模式通过--file-test-mode指定官方提供了几种seqwr顺序写入seqrewr顺序重写seqrd顺序读取rndrd随机读取rndwr随机写入rndrw混合随机读写我强烈建议先跑一轮rndrw因为真实业务数据库、Web应用大多是随机读写混合这个模式最能反映问题。sysbench fileio --file-total-size8G --file-num32 --file-test-moderndrw --file-block-size4K --file-io-modesync --file-extra-flagsdirect --time60 --max-requests0 run参数说明参数含义建议--file-total-size8G测试文件总大小建议设为物理内存的2倍避免被page cache兜底--file-num32测试文件数量数量多点更贴合文件系统多文件并发场景--file-block-size4K单次IO块大小模拟数据库随机读写场景用4K/8K大文件拷贝用1M--file-io-modesyncIO模式可选sync或asyncsync更贴近传统应用行为--file-extra-flagsdirect绕过page cache直接访问磁盘测试“真实磁盘性能”必加--time60测试时长磁盘类测试建议至少60秒避免缓存带来的虚高--file-extra-flagsdirect这个参数特别关键它绕过操作系统page cache直接通过O_DIRECT方式访问磁盘这样才能测出磁盘真实性能。如果不加这个参数操作系统会把大量读请求用内存缓存直接命中测出来的结果虚高到离谱尤其在文件总大小小于内存的情况下更是这样。测试结束后输出里最重要的指标是以下几项File operations: reads/s: 1234.56 writes/s: 1234.56 Throughput: read, MiB/s: 4.82 written, MiB/s: 4.82 General statistics: total time: 60.0008s total number of events: 123456判断磁盘性能水平时主要看read, MiB/s、written, MiB/s和latency (ms) avg。随机4K读写如果平均延迟超过20ms说明这块盘的随机IO性能不怎么样得看看是不是机械盘或者RAID配置有问题。测试完之后记得要清理sysbench fileio --file-total-size8G --file-num32 cleanup不执行cleanup的话8GB的测试文件就会留在磁盘上批量测试或者多次测试下来磁盘空间会被白白吃掉。我就因为偷懒没清理在测试机上堆积了上百GB的fileio测试残留文件。6.2 缓存、文件系统、RAID对IO测试的影响同样的磁盘在不同的文件系统下测出来的数字能差出一大截。比如xfs和ext4在顺序读写上的差距不算大但在元数据操作繁重的随机小文件场景下表现有明显差异。所以当你做磁盘性能对比的时候务必要确认两台机器用的文件系统一致。RAID级别的影响也很大。RAID10随机读写性能总体优于RAID5因为有镜像可以并行读RAID5的写惩罚读-改-写会让随机写性能明显打折。如果你发现一台机器的rndwr结果远低于预期先检查一下底层RAID配置而不是一上来就怀疑sysbench用法不对。还有一个隐蔽的影响因素是磁盘的调度器。CentOS 7默认的I/O调度器是cfq或deadline视内核版本而定不同的调度器在随机读写下的表现差异很大。特别是用NVMe SSD的时候建议改用nonenoop调度器因为NVMe设备内部已经有非常成熟的队列管理机制内核再去做调度反而画蛇添足。查看和修改调度器的方法# 查看当前调度器 cat /sys/block/sda/queue/scheduler # 临时修改为none echo none /sys/block/sda/queue/scheduler就我实测的经验同一块NVMe盘用cfq调度器测随机读时延会比none高出30%以上。这个差距不是sysbench的问题而是内核IO路径上的调度开销。6.3 文件IO结果解读的几个常见坑测试数据怎么看跟你选的目录、文件系统、存储介质都强相关这边列几个我亲测踩过的坑。第一文件总大小必须大于物理内存的两倍。不然你测的是page cache命中性能不是磁盘性能。8G文件配8G内存测试结果几乎全被内存缓存兜底读出几千MiB/s都有可能而这个数字是没有意义的。正常的磁盘随机读测试NVMe SSD能跑到几百MiB/s到1GiB/sSATA SSD大概两三百MiB/s机械盘只有个位数到几十MiB/s。第二压测前先把缓存清掉。如果测试文件被系统缓存了一部分跑出来的数字会偏快。可以执行sync echo 3 /proc/sys/vm/drop_caches清完缓存再跑数据才接近真实水平。当然如果是测试生产环境的在线服务器这个操作要谨慎drop_caches虽然无损但还是会短暂影响性能。第三不要忽略latency数据。吞吐量MiB/s高不代表延迟低。很多业务对IO延迟极其敏感比如数据库的每一个查询可能都要经历一次随机读。sysbench输出的延迟分布latency percentile能帮你看清楚P95、P99延迟是多少。如果平均延迟正常但P99严重偏高说明这个存储系统可能存在偶发的毛刺在生产中这比吞吐量低更让人头疼。7. 实测过程中遇到过的几个经典问题7.1 aarch64上的EPEL源失效问题前面说过CentOS 7官方源已经停止维护EPEL源也跟着进入了维护模式。2024年之后很多镜像站把CentOS 7的EPEL包移到了archive目录下默认yum install会直接报404。解决方式很简单——用阿里云镜像的archive路径yum install -y https://mirrors.aliyun.com/epel/epel-release-latest-7.noarch.rpm sed -i s|^#baseurlhttp://download.example/pub/epel|baseurlhttp://mirrors.aliyun.com/epel| /etc/yum.repos.d/epel.repo sed -i s|^metalink|#metalink| /etc/yum.repos.d/epel.repo这几条sed命令的作用是把repo文件中的metalink注释掉强制走baseurl指向的镜像地址。如果不改yum makecache阶段还是会去访问已经失联的下载源。7.2 某些二进制工具在ARM上直接跑不了指令集问题ARM平台的兼容性坑不止在sysbench很多第三方二进制工具在aarch64上都会遇到“指令不支持”的问题。我印象最深的是一个数据分析流程里的工具运行时直接报错This CPU does not support AVX, which is required.这个报错的意思是这个工具编译时使用了x86的AVX指令集而ARM CPU根本没这个指令自然跑不了。遇到这类问题别纠结看看有没有源码包改成源码编译或者找供应商要aarch64版本。sysbench本身没有这个坑因为它有官方的ARM版本但这件事提醒我们在做ARM平台规划时不只是sysbench能跑就行你整个软件栈里所有的二进制工具都得逐一确认是否有aarch64版本。我建议把“工具清单 架构支持情况”列成一张表逐个勾选否则到上线前才发现某个核心组件在ARM上跑不了就很被动了。7.3 CPU频率调度策略影响测试结果ARM服务器在默认的powersave或者ondemand频率调度策略下跑出来的性能数据可能比performance策略低不少。尤其是短时间的单线程测试CPU频率还没拉起来测试就结束了。测试之前建议把CPU调到performance模式# 安装cpufrequtils yum install -y cpufrequtils # 把所有核心设为performance模式 for cpu in /sys/devices/system/cpu/cpu[0-9]*; do cpufreq-set -c ${cpu##*/cpu} -g performance done设完之后用cpufreq-info确认当前策略。这个操作对保证测试数据可复现非常有帮助尤其是在多台机器做横向对比的时候。顺带说一句默认的powersave模式其实是服务器出厂最常见设置因为省电。测完之后记得把策略恢复回去避免机器在performance模式下功耗和发热上升影响机房散热。7.4 一次典型的“内存带宽偏低”排查过程之前有台ARM服务器内存带宽测试总是比同型号其他机器低30%左右我排查了一圈最后定位到是BIOS里内存频率的设置问题。那台机器的BIOS默认把DDR4内存跑在2133MHz而标称支持3200MHz导致带宽上不去。这种问题用sysbench暴露得特别快同样的线程数、同样的block size测出来的MiB/sec就是比别的机器低一截。后来进BIOS开启XMP/DOCP内存配置把频率拉到标称值再跑一次带宽数据恢复到正常水平。这个案例我想表达的是sysbench这类基准测试工具的另一个价值它是硬件配置问题的“照妖镜”能帮你快速发现机器是否运行在预期状态。很多时候不是代码有问题而是机器本身没调好。7.5 大量测试后的“内存碎片”问题还有一次我连续在机器上反复跑内存测试和文件IO测试几个小时下来发现系统变得有些卡顿free -h显示内存还有很多但跑新的测试进程时响应很慢。最后发现是长期大块内存分配和释放导致了内存碎片化连续性大块内存分配变慢。sysbench不像专门的可靠性测试工具那样会长时间冲击系统但如果你在短时间内在同一台机器上做大量测试建议在每轮测试之间隔几秒或者重启一下测试进程让系统喘口气。尤其是内存测试的--memory-total-size如果设得很大比如总内存的1.5倍以上频繁分配/释放会让内核内存管理模块压力陡增。8. 测试结果怎么用给自己一份可对比的数据台账跑到这一步你在每台机器上都已经能顺利产出CPU、内存、IO三类的数据了。但测试完的机器一堆不同时间、不同配置跑出来的数据全堆在终端输出里时间一长就分不清哪个是哪个的。我建议每测完一台机器就按固定格式记录数据时间机器型号CPU型号核心数OS版本sysbench版本CPU单核(events/s)CPU全核(events/s)内存读带宽(MiB/s)内存写带宽(MiB/s)4K随机读(IOPS)4K随机写(IOPS)2025-01-10鲲鹏920Kunpeng 920-482664CentOS 7.91.0.2045228700145201288012.5k8.9k2025-01-11飞腾S2500FT-S250064CentOS 7.91.0.2039825400132501190011.8k8.1k2025-01-12Intel XeonSilver 421020CentOS 7.91.0.2068012500156001320010.2k6.5k有了这张表你才能回答“新到的这批机器跟旧机器比到底强在哪”“哪台机器适合做计算密集业务哪台适合做IO密集业务”这类问题。有一点我得特别说明数据台账记录的时候最好连测试时的CPU频率调度策略、文件系统类型、RAID级别一起记下来不然隔了俩月你再翻这张表可能会因为忘记当时的配置条件对数据产生误判。另外我的个人建议是每次升级内核或调整BIOS之后都把基准数据重测一遍。哪怕只是打了一个小补丁也可能因为内核IO路径的变化导致磁盘性能出现几个百分点的波动。关键业务上线前用小规模测试确认性能没退化这是个很便宜却很有效的习惯。sysbench给的是基准参考值不是业务的SLA承诺值。但只有先把基准参考值搞清晰了后面做容量规划、做压力测试、做性能调优才有坐标系。希望这篇文章能帮你把ARM平台上sysbench这套流程跑顺少踩一些我当年踩过的坑。