服务器参数表全是水分？教你几招，把机器性能的“底裤”扒干净
很多人一上来就看CPU主频，越高越好？那可不一定。
我以前遇到过个坑，买了一批高主频的机器跑数据库，结果还不如之前那批主频低的。为啥？架构不一样啊。就好比你开个法拉利在晚高峰的二环上跑，还没隔壁骑电动车的大爷快。
要量化CPU，咱们得从几个维度下手。
1. 也是最容易被忽视的：指令集和架构
哪怕核心数一样，主频一样，若是新一代架构（比如Cascade Lake对比Broadwell），那性能差异可是巨大的。得看 IPC（每时钟周期指令数）。这个参数表上通常没有，得测。
2. 实战测试：Sysbench
这玩意儿是把瑞士军刀，啥都能测，但测CPU最直观。
怎么测？找质数。虽然这事儿看起来挺无聊，但对CPU来说是个实打实的计算压力。
执行个栗子：
如果没安装先安装下：
apt update
apt install -y sysbench假设你要测是不是“真男人”，直接上 4 个线程（假设你机器有4核），算到 20000。
sysbench cpu --cpu-max-prime=20000 --threads=4 run这里有个坑大家注意下，线程数。如果你想看单核强不强，--threads=1。很多业务（比如早期的Redis，或者Node.js的主进程）是吃单核性能的。这时候你核多没用，单核弱就是弱。
如果我想看这机器满载行不行，那就把--threads设成你的CPU总核心数。
结果怎么看？
别光看 total time，那太浅了。看 events per second（每秒执行事件数）。
CPU speed:
events per second: 618.57这台机器跑了1500分，那台跑了1200分，高下立判。
3. UnixBench：业界的“老黄历”但好用
虽然这工具岁数比很多刚入行的兄弟都大，但它那个综合跑分（Index Score）还是挺能说明问题的。它不光算算术，还搞什么管道读写、进程创建。
这对于Web服务器很有参考价值，因为Web服务这就经常得派生进程、搞搞系统调用。
执行起来慢得要死，通常要跑半个多小时：
./Run跑完会给你个总分。以前我们那会儿，双核机器跑个1000分都觉得牛逼，现在随随便便几千分。这个分数是个综合指标，要是A机器比B机器分高30%，那基本就是全方位碾压。
4. 这里的坑：NUMA架构
有时候你发现机器明明很强，但跑某些程序就是慢。这时候你得看看 lscpu。
如果显示 NUMA node(s): 2 或者更多，你要小心了。这意味着这台机器有两个“CPU插槽”或者两组内存控制器。如果你的程序跨节点去访问内存，那延迟能让你怀疑人生。
测试的时候，要是没考虑到NUMA绑核，测出来的数据可能完全是忽悠人的。
内存：不仅是大，还得快
内存这块，老板通常只问：是64G还是128G？
但咱们搞技术的得问：带宽多少？延迟多少？
我有次接手一个Java应用，频繁Full GC，怎么调优都没用。后来发现是那台机器插了根低频内存条，把整体频率拉低了，内存吞吐上不去，对象回收慢。
1. 吞吐量测试：Stream
这是个经典工具。它主要测四个东西：Copy（复制）、Scale（乘法）、Add（加法）、Triad（混合）。
我们要编译一下它（C语言写的）：
#下载
wget https://raw.githubusercontent.com/jeffhammond/STREAM/master/stream.c
#编译
gcc -O2 -fopenmp stream.c -o stream执行：
./stream看啥指标？
看 Copy 和 Triad 的数值，单位是 MB/s。
A机器：80000 MB/s
B机器：120000 MB/s
这差距就大了去了。如果你的业务是像Spark、Hadoop这种内存计算密集型的，B机器绝对吊打A机器，哪怕A机器的CPU再好也没戏。
2. 延迟测试：Intel MLC (Memory Latency Checker)
下载地址：https://www.intel.com/content/www/us/en/download/736633/intel-memory-latency-checker-intel-mlc.html
Intel自家出的神器。虽然是Intel出的，AMD也能跑，就是可能会报几个错，忽略就行。
为什么要测延迟？
对于高频交易、或者Redis这种内存数据库，带宽没跑满，但延迟高一点点，QPS就掉得厉害。
./mlc --latency_matrix它会打出一个矩阵，告诉你从这个核访问那个核的内存需要多少纳秒。你会发现，跨NUMA节点的访问延迟可能是本地访问的2-3倍。这时候你就知道哪台机器的设计更合理了。
硬盘：最容易翻车的地方
说到硬盘，这是水最深的。SATA SSD、NVMe、SAS、HDD，还有各种云盘，五花八门。
厂商告诉你：最大读写速度 3000MB/s。
你买回来一测：几百MB/s。
然后你去找厂商，厂商说：哦，那是顺序读写，你这是随机读写。
去他大爷的顺序读写。咱们跑业务的，除了导数据备份，哪有多少纯顺序读写的场景？大部分都是随机IO。
测试神器：FIO
别用 dd 命令测硬盘！那个只能测个乐呵，完全没有参考价值，因为它受到缓存影响太大。要测就用 FIO。
但是 FIO 参数巨复杂，写不好脚本测出来的全是废纸。
怎么设计一个靠谱的硬盘测试方案？
一定要分场景：
场景一：模拟数据库（随机读写，对延迟敏感）
数据库通常是 4k 或 8k 的小块读写。
fio -filename=/data/testfile -direct=1 -iodepth=128 -thread -rw=randrw -ioengine=libaio -bs=4k -size=10G -numjobs=4 -runtime=60 -group_reporting -name=mytest这段代码啥意思？我给大伙拆解下，这都是知识点：
-direct=1：关键！ 绕过操作系统缓存。不加这个，你测的是内存速度，不是硬盘速度。-iodepth=128：队列深度。现在的NVMe盘如果不把队列塞满，跑不出性能。-rw=randrw：随机读写混合。-bs=4k：块大小4k，这是最考验硬盘IOPS的。
结果怎么看？
关注两个值：
- IOPS：每秒输入输出次数。普通的SATA SSD可能就几万，好的NVMe能上几十万甚至百万。
- lat (usec/msec)：延迟。这个最重要！看看 95th 或者 99th 的延迟是多少。
如果A机器 IOPS 很高，但 99% 的请求延迟都超过了 10ms，那这盘在高峰期绝对会卡顿。我们要的是稳，不是傻快。
场景二：模拟日志写入（顺序写）
这就是吞吐量测试了。
fio -filename=/data/testfile -direct=1 -rw=write -bs=1M ...把块大小改成 1M，模式改成 write。这时候看带宽（BW），比如 500MB/s 还是 2GB/s。
一定要做的操作：预热
如果你测的是新买的SSD，记得先全盘写满一遍数据再测。空盘和脏盘的性能有时候能差出一倍。很多云厂商给你的新盘跑分贼好看，用了一个月就开始掉速，就是因为GC（垃圾回收）机制跟不上。
网络：不仅仅是带宽
网络这块，大家容易觉得：都是万兆网卡，有啥好测的？
非也。
我之前遇到过，两台机器都是万兆，但A机器跑Nginx的时候，并发稍微高点，系统负载就飙升。后来发现是A机器的网卡比较老，不支持某些硬件卸载（Offload）功能，或者中断亲和性没调好，导致CPU全去处理网络中断了。
1. 基础带宽：iperf3
这个最简单。
服务端：iperf3 -s
客户端：iperf3 -c <服务端IP> -t 60
但这只能告诉你路有多宽，不能告诉你路平不平。
2. 丢包与抖动：UDP测试
有时候TCP看起来跑满了，但应用层还是慢。试试UDP。
iperf3 -c <IP> -u -b 1000M看看Jitter（抖动）和Packet Loss（丢包）。
如果丢包率超过 0.1%，那对于分布式系统（比如Etcd、Zookeeper）来说就是灾难。
3. PPS（每秒包转发率）：真正的压力
对于做网关、做代理的机器，PPS比带宽更重要。很多时候带宽才跑了1Gbps，网卡就顶不住了，因为全是小包。
测试小包转发能力：
iperf3 -c <IP> -l 64 -t 60强制包大小为64字节。看看这时候能跑多少带宽，换算成PPS。A机器可能跑个50万PPS就CPU 100%了，B机器（如果有智能网卡SmartNIC加持）可能跑500万PPS还气定神闲。
综合实战：是骡子是马，拉个应用出来
前面说的都是基准测试（Micro-benchmarking），看着挺专业，但有时候跟真实业务场景是脱节的。
最能说明问题的，是回放流量或者模拟真实负载。
1. 编译Linux内核
这是个经典的“土办法”，但特别有效。编译内核涉及到大量小文件读写、密集的CPU计算、内存分配。基本上能把机器的综合素质摸个底。
下载个内核源码，make -j $(nproc)。
掐表计时。
A机器用了5分钟，B机器用了8分钟。那对于开发服务器或者构建服务器来说，A就是亲爹。
2. 数据库压测实战
如果你是用来跑MySQL的，直接上 sysbench-mysql。
准备数据：
sysbench oltp_read_write --table-size=1000000 --tables=10 prepare压测：
sysbench oltp_read_write --table-size=1000000 --tables=10 --threads=64 --time=300 run这里要重点观察 TPS（每秒事务数）和 QPS。
有个细节： 跑压测的时候，一定要在另一台终端开着 iostat -x 1 和 top。
观察 A 和 B 两台机器在同样 QPS 下的资源消耗。
- 如果是 A 机器 QPS 5000，CPU 吃了 40%。
- B 机器 QPS 5000，CPU 吃了 80%。
那显然 A 机器的余量更大，抗突发能力更强。效率比也是好坏的一个重要指标。
还有些“软”指标，看不见但要命
除了上面那些硬碰硬的数据，还有几个点，是我多年踩坑总结出来的：
1. 功耗与散热（如果你能接触到物理机）
有些机器跑分高，但是像个火炉。风扇一转起来跟直升机起飞似的，机房噪音直接拉满。更可怕的是，温度一高它降频啊！
我以前被坑过，测试只跑了5分钟，性能无敌。上线跑了俩小时，机箱热得发烫，CPU主频直接锁死在最低档，业务全挂。
所以，测试的时候，要跑长跑！起码满载烧机1个小时以上，看性能曲线是不是一条直线。如果是一条下坡线，这机器就是垃圾。
2. 扩展性
A机器只有2个PCIe插槽，B机器有6个。现在看着没区别，等你想加个NVMe硬盘卡或者万兆网卡的时候，A机器就得扔了。这虽然不是性能指标，但绝对是“好机器”的加分项。
3. 固件和驱动
有些新机器，硬件牛逼，但驱动稀烂。装个CentOS 7找不到RAID卡驱动，装个Ubuntu网卡时不时断连。
这种“软实力”的差距，往往在测试阶段很难发现，得去搜搜网上的吐槽，或者看看兼容性列表（HCL）。
怎么写报告给老板？
如果你只把上面那一堆命令的输出发给老板，老板估计会让你收拾东西走人。
你得做个表，还得有图。
对比维度建议：
- 计算密度：每核sysbench得分。
- IO延迟分布：FIO的99%延迟对比（画个柱状图，高下立判）。
- 网络吞吐成本：如果加上价格因素，算算每Gbps带宽的成本。
- 业务模拟结果：Mysql TPS对比。
最后得出一个结论：
“虽然B机器比A机器贵了10%，但在数据库场景下，TPS提升了30%，且延迟降低了50%。考虑到未来业务增长，建议采购B机器。”
这才是专业的运维该给出的答案。
总结一下
判断两台机器谁更好，绝不是看谁的CPU核多、谁的内存大。
- 看CPU：要看单核强不强（Sysbench），也要看多核协作有没有NUMA瓶颈。
- 看内存：带宽决定上限（Stream），延迟决定下限（MLC）。
- 看硬盘：别信最大速度，要看随机读写IOPS和延迟（FIO）。
- 看网络：带宽谁都有，PPS才是硬道理。
- 看实战：编译个内核，压个数据库，模拟真实场景。
- 看稳定性：烧机一小时，不降频才是真男人。
咱们做运维的，就是要有一种“不信邪”的精神。厂商吹得天花乱坠，不如咱们一行命令跑出来的结果实在。数据不会撒谎，前提是你得会问（测试）它。
行了，今天就唠到这。如果你觉得这些测试方法对你有用，或者你在测试过程中遇到过什么奇葩的坑，欢迎在评论区跟我聊聊。
公众号：运维躬行录
个人博客：躬行笔记
