Linux性能压测需围绕业务场景设计可复现、可对比、可归因的闭环过程，核心是明确目标、控制变量、采集全栈指标、定位并验证瓶颈。
Linux性能压测不是单纯跑满CPU或打爆网络，而是围绕业务场景设计可复现、可对比、可归因的测试过程。核心在于明确目标、控制变量、采集关键指标、定位瓶颈。
明确压测目标与场景
压测前必须定义清楚“测什么”：是单机Web服务吞吐量？数据库TPS上限？还是分布式系统在千并发下的响应延迟稳定性？目标不同，工具选型、监控维度、数据采集粒度都不同。
- 典型目标示例：Nginx静态文件服务在2000并发连接下，P95响应时间≤50ms，错误率＜0.1%
- 避免模糊表述，如“看看系统能扛多大”，这会导致结果无法评估、问题难以复现
- 优先模拟真实流量特征（如请求比例、会话保持、思考时间、动态参数）而非纯线性递增并发
选择合适压测工具并配置基准流量
工具只是手段，关键是能否精准构造符合目标的负载。常用组合如下：
- HTTP/HTTPS接口：wrk（轻量高并发）、hey（Go编写，简单易用）、k6（支持JS脚本+可观测集成）
- 数据库：sysbench（MySQL/PostgreSQL通用）、pgbench（PostgreSQL原生）、tpcc-mysql（事务一致性场景）
- 系统级混合负载：stress-ng（CPU/内存/IO/磁盘压力注入）、fio（块设备IO性能验证）
- 注意：压测机自身不能成为瓶颈——确保其CPU、网络、连接数充足，与被测机隔离部署（不共用同一台物理机或宿主机）
全过程监控关键性能指标
只看应用层返回码和响应时间远远不够。需同步采集操作系统、内核、服务进程三层面数据：
- 系统层：使用sar -u -r -n DEV -b 1持续记录CPU、内存、网卡收发、磁盘IO；重点关注%wa（IO等待）、%soft（软中断）、rx/tx丢包率
- 进程层：top/htop观察RSS/VIRT、上下文切换（cswch/s）、线程数；pidstat -t -p [PID] 1 查看线程级CPU与IO等待
- 内核与连接：ss -s 查看socket统计；netstat -s 看TCP重传、连接失败次数；cat /proc/net/snmp 看ICMP/TCP异常计数
- 建议用Prometheus + Node Exporter + Grafana搭建长期监控面板，压测前后对比基线变化
分析瓶颈并迭代验证
压测不是一次性动作，而是一个“施压→观测→假设→调优→再压”的闭环：
- 若CPU使用率未达80%，但QPS上不去 → 检查是否受锁竞争（perf record -e sched:sched_stat_sleep）、GC停顿（Java应用jstat）、或外部依赖（DB慢查询、Redis超时）
- 若%wa高且iowait集中在某块盘 → 用iotop定位进程，结合fio确认磁盘IOPS/延迟是否已达硬件极限
- 若大量TIME_WAIT或连接拒绝 → 检查net.ipv4.ip_local_port_range、net.ipv4.tcp_tw_reuse、net.core.somaxconn等内核参数是否合理
- 每次只调整一个变量（如仅调大fs.file-max，或仅开启TCP Fast Open），再重新压测验证效果
