长时间高压下的稳定性测试是为了验证系统在持续压力下是否会出现性能劣化(如吞吐量下降、响应变慢)或资源泄露(如内存、连接数持续增长)等问题。
测试目标和压力模型
在开始之前,首先要明确测试的终点,即系统在长时间、高负载下需要达到的稳定标准:
指标波动:系统的吞吐量(TPS/QPS)、响应时间(P95/P99)等性能指标,波动必须在可接受的范围内。
无资源异常:整个测试周期内,不能出现内存泄漏、句柄泄漏、数据库连接池耗尽等问题。
无系统错误:系统日志中不因压力而产生新的 warning、error 或 fail 信息。
压力模型通常有以下几种:
恒定压力:这是最经典的模型,让系统在相对饱和的压力下(例如,达到系统最大TPS的80% )持续运行较长时间(如8小时、24小时甚至72小时以上),用以检验系统的长期耐力。
压力变化:模拟真实业务场景中存在峰谷变化的压力模型,比如早晚高峰的压力峰值,以考验系统应对流量突增的能力。
异常注入:在恒定压力的基础上,主动注入异常(如CPU波动、网络延迟、节点重启等),来检验系统的自愈和容错能力。
监控资源:
在长时间测试中,系统资源监控是发现隐患的关键。你需要持续追踪以下核心指标:
CPU使用率:观察是否存在长时间高负载运行或异常的尖刺。若CPU使用率随时间持续攀升,可能是低效代码或死循环导致。
内存与交换:内存泄漏是稳定性测试的头号大敌。需重点监控内存占用量是否随时间线性增长,以及交换分区(Swap)的使用情况。
磁盘I/O:监控磁盘的读写吞吐量(rkB/s, wkB/s)和I/O等待时间。异常增高可能表明系统在频繁进行磁盘操作,成为性能瓶颈。
网络:监控网络接口的流量(rxkB/s, txkB/s)、数据包丢失率和延迟波动。
应用层资源:关注数据库/Redis连接池使用率、文件句柄数、JVM堆内存使用情况及GC频率、线程状态及死锁以及缓存命中率。
工具链从压测到监控
一套完整的工具链能帮你高效地完成测试。
压力生成工具
Apache JMeter:开源性能测试的事实标准,支持通过GUI或命令行(jmeter -n -t plan.jmx -l result.jtl)执行测试。
Stress-ng:Linux系统下的压力工具,支持CPU、内存、I/O等多维度压力模拟。
商业及云平台:如 Parasoft LoadTest、阿里云PTS、泽众P-One等,提供更全面的管理和分析能力。
资源监控工具
sar (System Activity Reporter):Linux系统自带的强大工具,适合记录历史数据用于分析。
bash
# 监控CPU,每60秒采样一次,共60次
sar -u 60 60 >> /tmp/cpu_stability.log
# 监控内存
sar -r 60 60 >> /tmp/memory_stability.log
# 监控磁盘
sar -d -p 60 60 >> /tmp/disk_stability.log
# 监控网络
sar -n DEV 60 60 >> /tmp/network_stability.log
nmon:一个常用的实时监控和报告生成工具。
JMeter PerfMon插件:配合部署在服务器上的ServerAgent,可以在JMeter中直接收集并展示服务器资源图表。
基础命令行工具:top/htop (CPU/内存)、vmstat (系统整体)、iostat (磁盘I/O)、free (内存) 等,用于快速查看。
可视化监控栈:InfluxDB + Grafana 的组合能提供强大的实时数据可视化和告警能力,非常适合长时间测试。
容器/Pod监控:对于容器化环境,可使用 cAdvisor 来监控容器资源使用情况。
如何判定稳定性?
在长时间测试结束后可以通过以下标准来判定系统是否稳定通过:
性能指标:吞吐量(TPS)的波动率应在一个合理范围(例如不超过30%);响应时间的P95/P99分位数应保持稳定,不应随时间推移而持续升高;错误率应趋近于0或在允许的阈值内。
资源指标:所有监控的资源指标,其使用量不应呈现单向、持续的增长趋势,例如内存占用率不能持续上升。
日志与错误:系统日志中不应出现大量非预期的 warning、error 或 fail 信息。
注意事项
测试时长要足够:对于核心系统,建议至少运行24小时以上,才能有效暴露缓慢的内存泄漏等问题。
注意冷启动和热结束:测试刚开始和刚结束时,系统资源波动通常较大。分析时应剔除开始和结束前几分钟的数据,关注稳定运行阶段的数据。
环境要贴近生产:测试环境(硬件、网络、软件配置)应尽可能与生产环境一致,避免因环境差异导致测试结果失真。
保存现场数据:务必保存所有监控日志、压测结果和系统日志。如果发生崩溃,保留内存快照(Heap Dump) 是定位问题的关键。