1. 从一台看起来没问题的服务器说起机房巡检的时候最怕遇到那种什么告警都没有但业务就是慢的机器。CPU使用率不高内存也够磁盘IO看着也正常可一到业务高峰期响应时间就往上飙。你登录上去查半天日志干干净净监控曲线四平八稳最后只能归结为玄学。这种场景我在过去几年里遇到过不下十次而其中相当一部分问题的根源最后都指向了同一个被忽视的环节——服务器硬件测试选型。不是硬件坏了而是当初选型的时候就没选对或者说没有针对实际业务负载去做过验证。这一章我想聊的就是这件事。它不像装系统、配网络那么有即时反馈也不像调优参数那样能立刻看到QPS变化但它决定了你这台机器未来两三年能不能稳定扛住业务。说白了硬件测试选型是运维工作中最前置也最容易被敷衍的一环。很多人买服务器就是看预算、看品牌、看配置单觉得差不多就行结果上线之后才发现各种不匹配。这篇文章适合谁看如果你是刚接手服务器采购或机房管理的运维或者你所在团队正准备批量上架新机器又或者你只是想知道为什么同样的配置别人跑得比我快那接下来的内容应该能帮你少走一些弯路。我会从需求拆解、测试方法、配件选型、套餐化思路几个角度把这件事讲透。2. 先搞清楚业务到底吃什么资源2.1 别用配置单思维去选服务器很多团队选服务器的流程是这样的业务方说要一台服务器运维问什么配置业务方说跟上次那台差不多就行然后运维照着上一台的配置单再买一台。这个流程看起来高效实际上埋了很大的雷。因为业务是在变化的。半年前那台机器跑的是单体应用现在可能已经拆成了微服务加了缓存层数据库也独立出去了。负载特征完全不一样你还照着老配置买要么浪费钱要么不够用。我习惯的做法是在选型之前先做一次资源画像。具体来说就是回答下面几个问题这个业务是CPU密集型、内存密集型、IO密集型还是网络密集型峰值负载大概是均值的多少倍峰值持续多久数据是热数据为主还是冷热混合有没有大量随机读写业务对延迟敏感还是对吞吐敏感未来一年有没有可预期的增长这几个问题不需要特别精确的答案但必须有方向性的判断。比如一个跑实时推荐的业务那基本就是CPU和内存双密集磁盘反而要求不高一个做日志聚合的业务那就是IO和网络密集CPU够用就行。2.2 用压力测试代替拍脑袋有了资源画像之后下一步就是验证。这里我要强调一个观点不要相信任何纸面参数只相信实测数据。纸面参数的问题在于它是理想条件下的峰值。比如CPU标称主频3.0GHz但实际跑起来因为功耗墙、散热限制可能长期稳定在2.4GHz。内存标称3200MHz但如果你插了8条可能自动降频到2666MHz。这些细节在配置单上都不会写但会实实在在影响性能。所以我的做法是新机型到货之后先不急着上业务而是跑一轮基准测试。测试的内容根据业务类型来定业务类型重点测试项常用工具CPU密集型整数/浮点运算、多核扩展性sysbench cpu、stress-ng内存密集型内存带宽、延迟、大页性能stream、lmbenchIO密集型顺序/随机读写IOPS、延迟fio、dd网络密集型吞吐、PPS、连接数iperf3、netperf综合型混合负载下的资源争抢业务自身压测脚本这张表不是让你全跑一遍而是根据你的业务画像挑重点。比如你做的是Web服务那CPU和网络是重点IO只要不拖后腿就行。你做的是数据库那IO和内存就是命门CPU反而可以适当放宽。2.3 一个真实的选型翻车案例说个我亲身经历的事。之前有个团队要上一批新的缓存服务器业务方给的配置是32核64GSSD。看起来没问题对吧结果上线之后发现缓存命中率一直上不去延迟比预期高了30%。排查了很久最后发现问题出在SSD的选型上。他们用的是消费级SSD顺序读写确实快但随机读写IOPS很低而且没有掉电保护。缓存场景恰恰是大量随机小IO消费级SSD根本扛不住。后来换成企业级NVMe SSD问题立刻解决。这个案例的教训是同样是SSD差别可能比SSD和HDD的差别还大。选型的时候不能只看是不是SSD还要看IOPS、延迟、耐久度、掉电保护这些指标。3. 硬件测试到底测什么怎么测3.1 CPU测试别只看核数CPU是服务器最核心的部件但也是最容易被误解的。很多人选CPU就看两个数核数和主频。实际上影响CPU性能的因素远不止这些。架构代际是第一位的。同样是16核新一代架构的IPC每时钟周期指令数可能比老一代高20%以上。这意味着即使主频相同新架构的实际性能也更强。所以选CPU的时候优先选新代际哪怕核数少一点。缓存大小也很关键。L3缓存越大多核之间的数据共享效率越高对数据库、缓存这类业务提升明显。我见过同核数同主频的两款CPU因为L3缓存差了一倍实际业务性能差了15%。内存通道数经常被忽略。CPU支持几通道内存直接决定了内存带宽上限。如果你买了支持8通道的CPU却只插了4条内存那带宽就浪费了一半。对内存密集型业务来说这是实打实的损失。测试CPU的时候我一般用sysbench跑多核质数计算同时用mpstat观察每个核的利用率。重点看两个东西一是多核扩展性核数翻倍性能是不是也接近翻倍二是频率稳定性长时间跑会不会降频。# 跑一个4线程的CPU测试持续60秒 sysbench cpu --threads4 --time60 run # 同时另开一个终端观察频率 watch -n 1 grep cpu MHz /proc/cpuinfo如果发现跑了几分钟之后频率明显下降那说明散热或供电有瓶颈这种机器上业务要慎重。3.2 内存测试带宽和延迟是两回事内存这块很多人只关注容量忽略了带宽和延迟。实际上对性能影响最大的是带宽其次是延迟。带宽决定了单位时间能搬运多少数据对大数据、缓存、虚拟化这类业务至关重要。延迟则影响单次访问的响应速度对数据库、实时计算这类业务更敏感。测试带宽我推荐用stream它能测出实际的内存拷贝、缩放、求和性能。测试延迟可以用lmbench或者更简单的lat_mem_rd。# stream测试编译后运行 ./stream # 观察输出中的Triad项这是最接近实际业务的指标这里有个坑要注意内存插法会影响性能。同样是8条内存插满所有通道和只插一半通道带宽可能差一倍。而且不同主板的内存插槽优先级不一样插错了可能连通道都识别不全。所以上架之前一定要对照主板手册确认插法。另外内存频率也不是越高越好。高频率内存往往时序更宽松实际延迟可能反而更高。而且频率越高稳定性风险越大。我的经验是选主流频率比如2666或2933不要盲目追高。3.3 磁盘测试IOPS、吞吐、延迟三角磁盘是服务器里最复杂的部件因为它的性能维度最多。IOPS、吞吐、延迟这三个指标在不同业务场景下的重要性完全不同。IOPS每秒读写次数对随机小IO敏感比如数据库、缓存。吞吐每秒传输数据量对顺序大IO敏感比如日志、备份。延迟单次IO的响应时间对实时性要求高的业务敏感。测试磁盘我一般用fio因为它能模拟各种负载模式。下面是一个模拟数据库负载的例子# 模拟随机读写块大小4K队列深度32 fio --namerandrw --ioenginelibaio --direct1 \ --rwrandrw --bs4k --size10G --numjobs4 \ --iodepth32 --runtime120 --group_reporting跑完之后重点看iops和lat两项。如果延迟超过1ms那对数据库来说就偏高了。如果IOPS远低于标称值那可能是队列深度不够或者磁盘本身有问题。这里有个经验企业级SSD和消费级SSD的差距在随机读写场景下可能是10倍以上。消费级SSD的随机IOPS可能只有几万企业级能到几十万。而且企业级SSD有掉电保护突然断电不会丢数据。所以只要预算允许磁盘一定要选企业级。3.4 网络测试带宽之外的PPS和连接数网络测试很多人只测带宽用iperf3跑一下看到接近万兆就满意了。但实际上PPS每秒包数和连接数同样重要。PPS决定了小包处理能力。如果你的业务是大量短连接比如API网关那PPS就是瓶颈。连接数则决定了并发能力对负载均衡、代理这类业务很关键。测试PPS可以用pktgen或者netperf的TCP_CRR模式。测试连接数可以用wrk或ab压测同时观察ss -s的输出。# 用netperf测试TCP连接建立速率 netperf -H 目标IP -t TCP_CRR -l 60 # 观察连接数变化 ss -s如果PPS上不去可能是网卡中断没做多队列绑定或者CPU单核跑满了。这时候需要调整中断亲和性把中断分散到多个核上。4. 配件选型那些配置单上不会写的细节4.1 电源别在最后一块钱上省电源是服务器里最不起眼但最不能省的部件。我见过太多因为电源问题导致的诡异故障随机重启、性能抖动、硬盘掉线。选电源的核心原则是冗余和品质。冗余就是至少11有条件上22。品质就是选大品牌、高转换效率的型号。转换效率高不仅省电发热也小间接提升稳定性。另外要注意电源功率。很多人按整机功耗的1.2倍选电源这其实不够。因为电源在50%负载时效率最高而且要考虑峰值功耗和老化衰减。我的经验是按整机满载功耗的1.5到2倍选。4.2 散热风道比风扇数量重要散热这块很多人觉得风扇越多越好其实不对。风道设计才是关键。如果风道乱了风扇再多也是白搭。机架式服务器一般有明确的前进后出风道你要做的就是确保所有挡板都装好不要留空位。因为空位会导致气流短路前面的冷风还没经过CPU就跑到后面去了。另外散热硅脂也有讲究。原厂硅脂一般够用但如果你对散热要求高可以换成高性能硅脂能降个几度。不过要注意换硅脂有风险涂不好反而更差没经验的话不建议动。4.3 RAID卡缓存和电池是灵魂如果业务需要RAID那RAID卡的选择就很重要。核心看两个东西缓存大小和掉电保护。缓存越大RAID卡的写性能越好。因为写操作先写到缓存再批量刷到磁盘能大幅提升IOPS。但缓存必须有掉电保护否则突然断电会导致数据丢失。掉电保护一般靠电池或超级电容实现。我见过有人为了省钱买了带缓存但没电池的RAID卡结果机房一次意外断电数据全丢了。这个教训太深刻了。4.4 网卡多队列和卸载功能网卡的选择除了看带宽千兆、万兆、25G还要看多队列和卸载功能。多队列能让多个CPU核同时处理网络中断提升PPS。卸载功能如TSO、GSO、GRO能让网卡分担一部分CPU工作降低CPU占用。选网卡的时候优先选支持多队列的型号队列数最好和CPU核数匹配。另外如果是虚拟化场景还要看是否支持SR-IOV这能大幅提升虚拟机网络性能。5. 套餐化把选型经验沉淀成标准5.1 为什么要做套餐化每次买服务器都重新选型效率太低而且容易出错。更好的做法是套餐化把常见的业务场景抽象成几个标准套餐每个套餐对应一套经过验证的配置。套餐化的好处很明显采购效率高直接选套餐不用每次重新评估。质量可控套餐都是经过测试验证的不会踩坑。运维简单同套餐的机器配置一致备件通用维护方便。成本优化批量采购同配置议价空间更大。5.2 套餐怎么划分套餐划分的依据是业务类型而不是预算。我一般会分这么几类套餐类型适用场景核心配置特征计算型应用服务器、批处理高主频多核CPU中等内存普通SSD内存型缓存、内存数据库中等CPU大容量高带宽内存企业级SSD存储型数据库、日志中等CPU中等内存高IOPS企业级SSD或NVMe网络型网关、代理、负载均衡中等CPU中等内存多队列万兆网卡通用型混合负载、测试环境均衡配置性价比优先每个套餐还要定义最小规格和推荐规格方便根据业务规模灵活选择。5.3 套餐的验证和迭代套餐不是定完就完了还要定期验证和迭代。我的做法是新套餐上线前跑一轮完整的基准测试记录各项指标。每季度抽检在用套餐确认性能没有明显衰减。每年根据业务变化和技术更新评估套餐是否需要调整。验证的时候重点看实际业务负载下的表现而不是单纯的跑分。因为跑分高不代表业务跑得好两者之间可能有很大差距。6. 测试选型中的几个常见误区6.1 误区一跑分高就是好这是最常见的误区。跑分是在理想条件下测出来的实际业务负载复杂得多。一个跑分很高的机器可能在你的业务场景下表现平平。比如某款CPU在Cinebench跑分很高但你的业务是大量分支预测那实际性能可能不如另一款跑分低但分支预测优化的CPU。所以测试一定要贴近业务不能只看跑分。6.2 误区二配置越高越好配置高当然好但成本也高。如果业务根本用不到那么高的配置就是浪费。我见过有人给一个日活几千的Web应用配了64核128G结果CPU利用率长期在5%以下。选型的核心是匹配不是堆料。够用、稳定、有适当余量就是好配置。6.3 误区三忽略兼容性硬件之间的兼容性很重要但经常被忽略。比如某些RAID卡和某些SSD不兼容会导致性能异常甚至掉盘。某些内存和主板不兼容会频繁报ECC错误。避免兼容性问题的方法很简单查官方兼容性列表。主流服务器厂商都会提供兼容性矩阵选型的时候对照一下能避开大部分坑。6.4 误区四不做老化测试新机器到货很多人直接上业务不做老化测试。这是很危险的。因为硬件故障有个浴盆曲线早期故障率比较高。如果不做老化可能上业务之后才发现问题影响就大了。老化测试一般跑24到72小时用高负载压测同时监控温度、功耗、错误日志。如果期间出现任何异常都要排查清楚再上业务。7. 我个人的一些实操心得说了这么多最后分享几个我在实际工作中总结的小技巧。第一建立自己的测试基线。每次测试完把数据记录下来形成基线。以后新机器测试的时候跟基线对比一眼就能看出好坏。这个基线不需要多精确但要有。第二关注木桶效应。服务器性能取决于最慢的那个部件。如果CPU很强但磁盘很弱整体性能就被磁盘拖累了。所以选型的时候要均衡不要有明显的短板。第三留足扩展余量。业务增长往往比预期快选型的时候要留出扩展空间。比如内存插槽不要插满留几个以后加硬盘位不要占满留几个以后扩。第四重视固件版本。BIOS、RAID卡固件、网卡固件这些版本对性能和稳定性影响很大。新机器上架前确认固件是最新稳定版。但注意不要盲目追最新要选经过验证的稳定版。第五做好文档记录。每台机器的配置、测试数据、固件版本都要记录在案。出问题的时候这些记录能帮你快速定位。我见过太多团队因为没记录排查问题的时候两眼一抹黑。硬件测试选型这件事说到底就是用数据代替感觉用验证代替猜测。它不性感不刺激但它是运维工作的地基。地基打好了上面的楼才能盖得高、盖得稳。
