48核配置TPS差一倍？数据库一体机软硬协同性能调优实战

同样48核配置，TPS能差到一倍，这事我第一次在现场看到时也觉得很邪门。两台数据库一体机，CPU型号一样，内存条容量一样，连盘位数量都相同，压测脚本也是同一套，结果一台能跑到30万TPS，另一台死活只有15万，而且CPU Usage看着都差不多，都在80%上下。后来翻了一整天的硬件计数器、中断分布和锁等待，才确认问题不出在“配置”上，而在“协同”上——硬件和软件之间，数据库和内核之间，驱动和NUMA拓扑之间，有没有被当成一个整体去调，才是真正把性能分成三六九等的分水岭。

这篇内容不聊厂商宣传页上的TPC-C数字，就聊实打实的工程问题：为什么同样48核配置下TPS差距能拉一倍，数据库一体机的软硬协同到底协同了哪些环节，以及日常做压测时，TPS虚高、JMeter混合场景、单交易限流这些坑怎么避。适合正在选型数据库一体机、或者被性能测试报告迷惑过的运维和DBA朋友，也适合自己攒高性能数据库服务器的同学参考。

1. 同样是48核，为什么TPS能差出一倍？

1.1 48核看着没差别，实际已输在起跑线上

先说个扎心的现实：市场上所谓的“48核配置”，细看下来，差异极大。同样是两个CPU插槽，有的是单路48核，有的是双路各24核；同一代CPU里，有基础频率2.1GHz的节能版，也有基础频率3.0GHz的高主频版；内存通道有8通道和16通道的区别；甚至PCIe链路走向都直接影响外设访问延迟。48核只描述了一个维度，CPU核心数量，但数据库这种对内存带宽、缓存延迟、中断处理极度敏感的负载，真正拼的是多维度的综合表现。

举一个我在选型中常见的现象：两台机器CPU都是Intel 48核，其中一台是上一代架构，内存频率只有2933MHz，另一台是新一代架构，内存频率4800MHz。前者理论内存带宽约140GB/s，后者能到230GB/s。跑OLTP高并发负载时，性能瓶颈往往不是CPU算力，而是内存带宽和缓存一致性开销，光这一项差异就有接近30%的TPS差距。如果再叠加NUMA拓扑设计、存储介质的延迟差异，那一倍的TPS差距根本不夸张。

所以挑数据库一体机或者自己攒机器时，第一步就是把“48核”这个模糊描述拆开看：具体是哪一代CPU、主频多少、内存通道数和频率、NUMA节点怎么分布、存储是全NVMe还是混合介质、网卡是几万兆的、每个PCIe设备挂在哪个NUMA节点下。不把这些底账查清楚，后面谈性能调优都是空中楼阁。

1.2 CPU时间片耗尽的，从来不只有SQL语句

很多人觉得数据库负载高，CPU时间都花在执行SQL上了。这个认知在软硬协同做得好的机器上基本成立，但在协同做得差的机器上，CPU时间片会大量消耗在“和业务无关”的地方。

我曾经在一台机器上做过perf分析，结论相当惊人：CPU周期里只有55%真正用在了数据库执行SQL上，剩下的时间消耗在spinlock自旋、内存分配、cache miss后的内存访问等待、网卡中断处理上。尤其是高并发网络包场景，如果网卡队列没有和CPU核心做绑核，中断会在多个核心之间“漂移”，导致CPU cache反复失效。每次中断处理都是一次缓存刷新和上下文切换，几十万TPS的请求量下，这个开销会被放得很大。

数据库一体机和高性能自建机的分水岭，恰恰就在这里。软硬协同做得好的产品，会把网卡中断、存储队列、数据库线程、NUMA内存访问全部绑到最优的CPU核心上，让CPU大部分时间在跑业务而不是做“调度杂活”。这台机器的实际表现，和那台“配置相同但没人做系统级调优”的设备，TPS差出一倍就很正常了。

2. 软硬协同：一体机的“分水岭”到底分在哪里？

2.1 硬件层：NUMA感知和中断绑核是最容易被忽略的起点

数据库一体机做软硬协同，第一个动作就是处理NUMA拓扑。现代双路服务器里，CPU0和CPU1各有自己的内存控制器，CPU0访问本地内存延迟在80ns左右，访问远端内存延迟会翻倍到140ns甚至更高。数据库缓存池、排序区、临时表这种大量内存访问的负载，一旦线程跑到远端内存上，性能损耗立竿见影。

一体机在出厂时会做NUMA感知配置，典型做法是这样的：数据库实例的numa_interleave参数设为ALL或者按需设置，把大页内存尽量从本地节点分配；线程池的worker线程和CPU核心一一绑定，让同一个连接会话的请求始终在同一个NUMA节点上处理。很多自建数据库最常犯的错，就是开着默认配置，numactl策略不设置，数据库线程像无头苍蝇一样在两个CPU节点间乱窜，TPS从源头就低了两三成。

网卡中断绑核是另一个关键动作。Linux服务器上，irqbalance这个服务默认会把网卡中断在CPU核心间动态均衡，意图是分散负载，但数据库这种高并发网络包场景恰恰会被“动态均衡”害惨。每次中断漂移到新核心，CPU cache要重建，数据库连接的数据如果在旧核心的cache里，就要跨核心同步。正确做法是关闭irqbalance，把网卡的多个RX/TX队列分别绑定到固定的物理核心上，配合RPS/RFS确保同一个连接的数据包始终由一个核心处理。

2.2 内核和驱动：从“能用”到“压满”的关键距离

硬件层面定好骨架之后，内核和驱动参数是肌肉。软硬协同做得好的数据库一体机，通常会针对数据库负载定制内核参数，而不是直接拿通用发行版的内核默认值硬扛。

socket读写缓冲区调大、TCP拥塞控制算法换成适合低延迟内网的bbr、关闭IPv6等用不到的特性、减少irqbalance干扰，这些是基础操作。真正拉开差距的，是对锁竞争和内存分配器的优化。数据库高并发场景下，内核的spinlock、jemalloc或glibc malloc的锁竞争、文件系统日志提交的锁，都会成为瓶颈。

举一个具体例子：MySQL在开启binlog和redo双写时，fsync频率直接决定刷新性能。一体机厂商如果做了软硬协同，会把日志存储放到延迟极低的NVMe盘上，并把文件系统的mount参数调成noatime、nobarrier，数据库的innodb_flush_log_at_trx_commit和sync_binlog的配合方案也会针对硬件特性给出推荐值。自建环境如果只是“买台机器装个数据库”，硬盘延迟和文件系统参数都不管，TPS自然提不上去。

内存分配器方面，高并发多线程下glibc malloc的锁竞争是著名瓶颈。很多数据库一体机会在运行环境里预加载jemalloc或tcmalloc，把内存分配压力从锁竞争变成无锁的per-thread缓存。这一层优化看不见摸不着，但在一台48核机器上，动辄几万个并发内存分配请求，优化前后的TPS差距实测能有15%~20%。

2.3 数据库层：再好的硬件也要有人懂“翻译”

数据库内核参数的调优，是软硬协同的最后一公里。同一台机器，同一个硬件环境，数据库参数设置不同，性能可以差出好几倍。这个“好几倍”不夸张，我见过一台48核一体机，跑TPC-C类负载，innodb_buffer_pool_size从16G调到64G、innodb_thread_concurrency从默认值调整为48之后，TPS直接翻了近一倍。

不过参数调优不是把单个参数拉到最高就完事，而是要理解硬件拓扑。比如innodb_buffer_pool_instances，在多核机器上建议数量和内存池大小挂钩，避免单个buffer pool的锁竞争；比如max_connections，不是因为内存够就无限放大，要同时考虑线程栈、临时表、排序缓冲对内存的累积占用；比如MySQL 8.0的innodb_redo_log_capacity，如果redo文件太小，高并发下会频繁触发checkpoint刷盘，磁盘IO被浪费在日志上，TPS卡在一个莫名的低水平。

数据库层还牵扯SQL执行计划的问题，同样一条查询，统计信息不准时执行计划会走错索引，CPU、IO消耗成倍增长，TPS自然被拖累。一体机厂商在做软硬协同调优时，会针对测试模型调整优化器开关、统计信息采样策略和索引提示策略。这套东西不是安装完就自动生效的，需要经验积累。

2.4 一体化的本质：把每个环节的损耗压到最低

软硬协同的核心逻辑，是把从网络包进网卡、中断触发、数据拷贝到用户态、数据库线程处理、存储引擎读写、日志刷盘、返程ACK的全链路，每个环节的损耗都压到最低。单看任何一个环节，差距都不大；但全链路累积下来，就是50%到100%的TPS差值。

打个比方，一条高速公路上，每个收费站平均慢2秒，单看不严重；但全程10个收费站，一辆车过完全程就比别人慢20秒，换算成单位时间通过的车流量，差距就非常明显。数据库一体机的“分水岭”就是这条高速路的整体设计水平，而不是某一个收费站的速度。

所以评估一台数据库一体机时，不要只看广告页上的CPU核数和内存容量，要问清楚几个关键问题：NUMA策略是怎么配置的、网卡中断是怎么绑核的、文件系统参数用的什么推荐值、数据库参数集有没有针对高并发场景做过验证、有没有提供一整套可解释的性能调优基线。这些问题答得上来的厂商，才是真正做了软硬协同的；答不上来只是给你一台裸机硬件加默认安装的数据库，那本质上和自建没有区别。

3. TPS虚高的陷阱：为什么测试报告和线上表现对不上？

3.1 性能测试里的“TPS虚高”是怎么来的？

“TPS虚高”是最近圈子里讨论特别多的热词，因为太多人拿着压测报告里的数字去对比硬件性能，结果上线后被打回原形。TPS虚高本质上是测试方法造成的失真，最常见的几个来源：

第一，测试场景过于单一。只压一条主键点查SQL、只压纯插入、只压纯读不混合写，这种场景下数据库的锁竞争和IO压力都很小，TPS数字自然会非常好看。线上业务却是读写混合、范围查询、事务回滚、临时表排序、死锁重试混在一起，压力模型完全不同。

第二，没有控好并发模型。压测工具开几千个线程猛打，把数据库连接池打满，但每笔事务都很短，TPS数字高但平均事务延迟已经几百毫秒，这种TPS没有实际意义。真实业务不可能容忍几百毫秒的延迟。

第三，忽略了平稳性。TPS虚高还有一种情况是压出来的平均TPS很高，但曲线像锯齿一样剧烈波动，一会儿5万一会儿10万。这种不稳定性能上线后遇到流量高峰就会雪崩，越高平均值的意义越小。

第四，用了过大的连接池和忽略等待时间。很多压测脚本直接用JMeter的线程数当作并发用户数，没有给模拟用户设置思考时间，导致数据库承受了远比真实业务更高的压力，TPS数字看着高，但真实场景根本不会这样。

3.2 用JMeter做混合测试的正确姿势

要获得接近线上真实的TPS，JMeter做混合测试是最常用的手段。很多刚入门的朋友以为混合测试就是“同时跑几个Sampler”，其实远没有这么简单。混合测试的核心是模拟真实业务比例和操作节奏。

第一步，梳理业务事务模型。拿一个电商订单场景举例：用户浏览商品占60%，添加购物车占20%，提交订单占15%，支付回调占5%。这些比例要对应到JMeter的Sampler上，每个Sampler代表一类事务。

第二步，配置事务比例。JMeter里可以用Throughput Controller来控制事务比例，比如添加购物车的事务吞吐量设为20%，提交订单设为15%。注意ThroughputController的两种模式：Total Executions模式下设置的是执行次数比例，Percent Executions模式下设置的是百分比比例。实际项目里推荐用Percent Executions，因为更直观，也不会因为某个请求失败导致比例漂移。

第三步，设置合理的思考时间。真实用户操作之间是有间隔的，不会像机器一样猛点。JMeter里可以用Constant Timer或Gaussian Random Timer来模拟。高斯随机定时器比固定定时器更真实，比如浏览商品后停顿200~800毫秒再点下一个按钮。

第四步，连接池和数据库端的配合。JMeter压力机的连接池大小、JDBC配置里的最大连接数、数据库端的max_connections、thread_pool_size，都要提前对齐。不然压力机上先抛“Too many connections”，数据库端根本没收到压力，TPS数字就是假的。

一个实际项目中我常用的事务组合大概是这样的：

这套模型跑出来的TPS，比单纯压一条SQL要可信得多。选型对比时，不要看两家厂商各自报的“极限TPS”，而是用同一套混合测试模型、同一台压力机、同样的数据量去跑，看谁的曲线稳、谁的延迟低，这比看任何宣传数字都有价值。

3.3 怎么给某个交易限制TPS？限流模拟的两种玩法

“怎么给某个交易限制TPS”这个热词，反映的是在一体机选型和性能对比中，越来越多人开始关注业务隔离能力。毕竟真实业务里，某个突发流量大的交易（比如秒杀、支付回调）可能会把整个数据库打垮。实际压测时，主要有两种限制TPS的需求。

第一种是压测侧限制TPS，目的是模拟真实线上流量不会无限制增长。JMeter里实现单交易限流，最常用的是Constant Throughput Timer。给某个Sampler单独添加一个Constant Throughput Timer，设置target throughput为500，意思是这个交易每分钟只发500个请求，换算下来TPS约8.3。注意这个组件是按分钟计的，不是每秒；并且它是“尽力而为”的限流，实际TPS会略高于设定值，UDP包发多了它不管，只有TCP层的请求会被限流逻辑拦截。如果要对每秒精确限流，建议用jp@gc – Throughput Shaping Timer插件，用图表方式定义TPS曲线，JMeter会在每秒钟维护请求发送的节奏。

第二种是被测系统侧限制TPS，目的是保护核心交易不被打垮。一体机数据库层面做单交易限流，常见做法是在SQL网关或中间件层做令牌桶限流，比如对某类事务限定每分钟最多只能提交1000笔。在MySQL场景下，可以通过改写事务提交入口，在应用层加Redisson分布式限流器（RateLimiter），或者在数据库前面挂ShardingSphere的SQL限流规则，用HINT指定某个逻辑表的TPS阈值。实际项目中，我推荐在应用层做限流，因为数据库层的限流对绑定变量的SQL不太好做，容易误伤其他同结构的查询。

还有一个容易被忽略的细节：限制TPS后，要把“被动拒绝”变成“排队等待”。真实业务中，突发流量超过限流值后，用户应该看到“系统繁忙请稍后再试”，而不是连接直接被数据库断掉。一体机在高并发连接管理上如果做得不好，限流就会退化成“连接雪崩”，比不限流更可怕。

4. 一套可复现的高并发压测与调优流程

4.1 压测前的检查清单，少一项结果都不作数

做高并发压测之前，我建议先花半天时间把环境检查做完，不然测试结果大概率是废数据。检查清单可以按这个来：

第一，核对硬件和系统信息。用lscpu确认CPU型号、核数、主频、NUMA节点；用numactl --hardware确认内存分布；用lspci | grep -i nvme确认存储介质；用ethtool -i确认网卡型号和驱动版本。这些信息要记录在压测报告里，方便后面复现。

第二，确认内核参数和文件系统参数。sysctl -a看一下net.core.somaxconn、net.ipv4.tcp_max_syn_backlog、vm.swappiness等关键参数；mount | grep 数据盘目录，确认noatime、nobarrier这类挂载参数。两套环境对比时，这些参数不一致，光是TCP缓冲区大小不同，TPS就可能差10%。

第三，关闭不必要的中断均衡和节能策略。systemctl stop irqbalance、cpupower frequency-set -g performance，这些动作在正式压测前必须做。高性能数据库一体机出厂时一般已经做了，自建环境要自己手动处理。

第四，预热数据库。压测前先把数据量准备好，跑一轮小流量把buffer pool、索引页、统计信息都预热好，再进入正式压测。不然数据库刚开始数据全在磁盘，TPS从几千慢慢爬，数字很难看也没意义。

第五，约定统一的压测口径。TPS怎么算、延迟取平均值还是95分位、压测持续多久、并发数多少、混合比例怎么定，这些在对比前就要统一。我之前遇到过两家厂商，一家报TPS是峰值，一家报的是平均值，对比起来毫无意义。

4.2 从混合压测到瓶颈定位的实操思路

压测过程中，不要只盯着TPS数字，要同时采集系统侧的各项指标。TPS其实只是一个输出指标，CPU使用率、平均负载、上下文切换、中断数、内存带宽、磁盘IO延迟、网络重传率、锁等待、redo日志刷盘频率，这些过程指标才真正告诉你瓶颈在哪。

定位瓶颈的简易判断逻辑是这样的：

• 如果TPS上不去，但单个CPU核已经跑满，其他核很闲，先怀疑热点锁和SQL执行计划问题，用perf top看看热点函数在哪。
• 如果TPS上不去，CPU整体使用率不高，先怀疑内存带宽和NUMA访问问题，用numastat看看跨节点访问比例。
• 如果TPS上不去，CPU不高、内存不高，先看磁盘IO的await和util，重点确认redo日志和binlog的刷盘路径是不是瓶颈。
• 如果TPS上不去，所有指标都不高，优先怀疑网络层，看网卡软中断分布、TCP重传率、socket缓冲区是否太小。

有一次在一台新接手的机器上做混合压测，TPS卡在18万再也上不去，CPU整体才60%。用perf top一看，热点函数是que_spin_wait，数据库内部的行锁自旋。查了慢日志和锁等待，发现一个高频UPDATE事务和另一个高频SELECT事务在同一行记录上冲突严重，业务表里有一行“热点账户”被所有人同时更新。这种瓶颈加再多的CPU核都没用，得从业务逻辑上拆分热点行，比如把余额拆分成多条记录后汇总。后面我把这个事务改成先汇总再更新的方案，TPS直接从18万跳到32万。

4.3 常见问题与排查技巧实录

把我在压测和一体机调优中遇到最多的几个问题整理成速查表，这些经验都是拿真金白银的线上事故换来的：

还有一个很多人容易踩的坑：MySQL数据库使用“UUID主键”时，高并发插入的TPS极低，因为随机主键导致索引页频繁分裂和随机IO。换成自增主键或者有序UUID（比如UUID v7）之后，TPS能明显提升。这类问题不是软硬协同能解决的，但只有在压测混合场景时才会暴露出来，单一插入压测反而看不出来。

4.4 高性价比一体机的落地选型建议

最后聊一下选型判断。高性价比的数据库一体机，不等于“价格低的服务器加装数据库”，而是指在合理的成本下，通过软硬协同把硬件的性能压榨到极致。选型时不要光看48核、64核这种显性参数，要重点关注三个隐性能力：调优基线是否可交付、性能测试模型是否透明、出了问题能否快速定位到根本原因。

调优基线可交付，是指厂商能不能给你一份带解释的参数清单。为什么这个NUMA参数这么设置，为什么这个redo日志大小是这个值，每一项都讲得清楚。凡是说“这是我们的默认最佳配置，不需要改”的，大概率没做过针对你业务模型的调优。

测试模型透明，是指厂商提供的TPS报告要能还原。你拿同样配置的通用服务器装上社区版数据库，用同样的JMeter脚本去复现，能跑出多少TPS，差距到底是因为硬件能力还是因为调优差异，要能说得清楚。说不清楚的，性能报告就参考性存疑。

出了问题快速定位，是指一体机的监控和诊断体系。高性价比不仅仅是采购价便宜，更要算上长期运营的隐性成本。一台机器出了性能问题，排查三天找不出原因，三天人力成本可能已经超过机器差价了。一体机如果自带性能监控大盘、关键指标基线、自动化诊断工具，这部分价值往往被低估。

我个人在实际操作中的体会是：不要迷信任何一家厂商的纸面TPS，拿混合测试脚本实测，看不同并发度下的TPS曲线和延迟分布，才是判断软硬协同水平最靠谱的方法。同样48核配置，TPS差一倍这件事，既可能是硬件细节的差距，也可能是调优深度的差距，但最根本的，是产品有没有把从网卡到数据库的整条链路当成一个系统去优化。挑机器是短期决策，用机器是长期工程，设备到手后，把软硬协同的功夫做到位，才是把“高性价比”三个字真正落地的关键。