一、稳定性测试跟性能测试有什么区别性能测试看的是快不快稳定性测试看的是稳不稳。我们项目里定了一条硬性标准所有做了性能测试的业务都要在75% CPU压力下进行7×24小时的稳定性测试。为什么定75%因为生产环境的CPU不可能一直空载日常业务定时任务混跑CPU使用率长期在60%-80%之间是常态。我们在测试环境用75%的CPU压力跑七天就是为了模拟生产环境的真实负载情况。稳定性测试的目标就两个系统能不能持续稳定运行不崩溃、不重启系统性能会不会随时间衰减第七天跟第一天一样快我们跑了一轮七天稳定性测试结果发现的问题还真不少。下面按时间线一个个说。二、测试怎么设计的JMeter的配置跟性能测试类似但有一个关键区别持续时间从几个小时拉长到了七天。线程组的配置是这样的textNumber of Threads: 根据性能测试结果压到CPU 75%左右的并发数 Ramp-Up Period: 300秒5分钟慢慢加上去别一启动就把系统冲垮 Loop Count: Forever一直跑不停 Scheduler: 勾选Duration: 604800秒7×24小时四种业务场景采集任务、SparkSQL作业、质量规则、API接口同时跑混合加压模拟真实生产环境。监控方面我们部署了监控层面工具采集频率关注指标操作系统Prometheus Node Exporter15秒CPU、内存、磁盘、网络数据库Oracle Enterprise Manager1分钟会话数、等待事件、表空间大数据组件Ambari / Cloudera Manager1分钟YARN队列、HDFS使用率、Spark作业应用日志ELKElasticsearch Logstash Kibana实时错误日志、异常堆栈七天跑下来发现的问题依次是三、第一天到第三天一切正常前三天没什么异常。系统CPU稳定在73%-77%之间波动内存使用率平稳磁盘I/O正常所有任务的成功率都在99.5%以上。监控面板上一片绿色大家还挺乐观的。但到了第四天开始出问题了。四、第四天磁盘被日志写满现象第四天下午监控突然报警磁盘使用率超过了90%。登录服务器一看/u01/logs目录下全是日志文件最大的几个都超过了10GB。bash# 查看磁盘使用情况 df -h # /u01 使用率 92% # 查哪个目录占的空间最大 du -sh /u01/* | sort -rh | head -10 # /u01/logs 180G # /u01/data 120G # 看看日志文件多大 ls -lh /u01/logs/ # app.log.2026-01-18 12G # app.log.2026-01-17 11G # app.log.2026-01-16 10G # ...四天的日志加起来180G问题根因日志没有做轮转log rotation。所有的业务日志都往同一个文件里写写满了就新建一个但旧文件从来不删。四天就攒了180G的日志把磁盘撑爆了。临时处理手动清理了15天前的日志释放了150G空间。bash# 清理15天前的日志 find /u01/logs/ -name *.log.* -mtime 15 -exec rm -f {} \;长期解决方案写了一个日志自动清理脚本加入crontab每月执行一次。bash#!/bin/bash # /opt/scripts/clean_old_logs.sh # 每月1号凌晨3点执行清理30天前的日志 LOG_DIR/u01/logs RETENTION_DAYS30 find $LOG_DIR -name *.log.* -mtime $RETENTION_DAYS -exec rm -f {} \; find $LOG_DIR -name *.out -mtime $RETENTION_DAYS -exec rm -f {} \; # 记录清理结果 echo $(date): Cleaned logs older than $RETENTION_DAYS days /var/log/log_clean.log加入crontabbash# 每月1号凌晨3点执行 0 3 1 * * /opt/scripts/clean_old_logs.sh反思为什么是每月执行一次而不是每天执行因为磁盘是1TB的按照日志增长速度30天大约产生1.4TB的日志所以30天的保留策略刚好撑满。但生产环境的日志量可能会波动我们后来改成每天执行保留30天。五、第五天到第六天各种小问题陆续暴露日志问题解决之后第五天第六天相对平静但还是发现了一些小问题问题一连接池偶尔泄露有个采集任务的连接池配置了maxIdle10但代码里忘了在finally块里释放连接。跑了五天后连接池里积累了几十个僵尸连接导致新请求拿不到连接。现象是监控上看到活跃连接数慢慢上涨到了第五天下午突然有一个小时的成功率掉到了95%。排查手段查了应用的数据库连接池监控发现活跃连接数一直在涨从来不会降。抓了几个线程栈看到有线程持有连接但不释放。解决方案修改代码把连接释放逻辑放到finally块里确保不管成功还是异常都能释放连接。java// 修改前有泄漏 Connection conn dataSource.getConnection(); // 执行业务逻辑... // 如果这里抛异常conn就不会被关闭 // 修改后用finally保证释放 Connection conn null; try { conn dataSource.getConnection(); // 执行业务逻辑... } finally { if (conn ! null) { conn.close(); } }问题二Kafka消费者Rebalance频繁质量任务那边用的是Kafka消费者拉取数据跑着跑着发现消费者组频繁发生Rebalance重平衡每次Rebalance的时候消费就暂停了任务成功率短期下降。排查后发现是消费者的max.poll.interval.ms设置得太短默认300秒但质量任务处理每条消息的时间较长超过了300秒还没处理完Kafka就认为消费者死了触发Rebalance。解决方案把超时时间调长。properties# Kafka消费者配置 max.poll.interval.ms600000 # 从300秒调到600秒10分钟 max.poll.records100 # 每次拉取的消息数调小减少单次处理时间 session.timeout.ms45000 # 会话超时适当调长六、第七天性能衰减——第七天比第一天慢了很多现象第七天早上我们对比了一下监控数据发现了一个严重问题——第七天比第一天所用的时间更长。具体来说指标第一天平均值第七天平均值增幅SparkSQL作业平均耗时2.4分钟4.1分钟70%API平均响应时间135ms289ms114%采集任务平均耗时1.8秒/表3.5秒/表94%质量任务平均耗时8.2秒/表15.7秒/表91%所有任务的耗时都在变长而且越往后越慢。这是个典型的性能衰减问题。排查过程第一步看系统资源。CPU还是75%左右没变。内存使用率也没明显增长。磁盘I/O正常。资源层面没问题那就不是系统被压垮了而是某些资源被消耗了但没释放。第二步查数据库层面。连上Oracle查了一下临时表空间和UNDO表空间sql-- 查看临时表空间使用 SELECT * FROM V$TEMP_SPACE_HEADER; -- 临时表空间用了80%比第一天高了40% -- 查看UNDO表空间 SELECT tablespace_name, ROUND(used_space/1024/1024/1024, 2) as used_gb FROM DBA_TABLESPACE_USAGE_METRICS WHERE tablespace_name UNDOTBS1; -- UNDO用了120GB第一天只有30GB临时表空间和UNDO都在持续增长说明有些事务一直没有提交或者提交后空间没有被回收。第三步查长时间运行的事务。sqlSELECT sid, serial#, username, status, ROUND((SYSDATE - start_time) * 24, 2) as hours_running, sql_text FROM V$SESSION JOIN V$SQL ON V$SESSION.sql_id V$SQL.sql_id WHERE status ACTIVE AND start_time SYSDATE - 1/24 -- 运行超过1小时 ORDER BY start_time;发现有3个事务已经跑了6个小时还没结束一直在执行大量的INSERT操作。这些长事务持有UNDO段不释放导致UNDO表空间越涨越大其他需要读取一致性视图的操作就变慢了。第四步找到长事务的源头。顺着SID查了应用的日志发现是质量任务里有一个脚本做了全量数据的行数校验对一张30亿行的表执行了SELECT COUNT(*)。这个查询需要读取全表数据同时为了保证读一致性需要用到UNDO里的历史数据。UNDO被撑得越大查询就越慢形成了一个恶性循环。问题根因质量任务的SQL写得有问题——对超大表执行全表COUNT(*)不仅自己慢还撑爆了UNDO拖累了整个系统的性能。解决方案终止了那个跑了6小时的查询sql-- 终止长事务 ALTER SYSTEM KILL SESSION sid,serial#;优化质量任务的SQL用统计信息代替全表COUNTsql-- 原来的写法30亿行全表扫描 SELECT COUNT(*) FROM huge_table WHERE dt 2026-01-15; -- 优化后的写法查分区统计信息 SELECT num_rows FROM DBA_TAB_PARTITIONS WHERE table_name HUGE_TABLE AND partition_name P_20260115;清理UNDO表空间回收空间sql-- 切换UNDO表空间让旧的UNDO段释放 ALTER SYSTEM SET UNDO_TABLESPACE UNDOTBS2; -- 等旧事务全部结束后再切回去最终效果优化之后我们又跑了一轮7天稳定性测试这次第七天的性能跟第一天基本持平指标第一天第七天变化SparkSQL作业平均耗时2.4分钟2.6分钟8.3%API平均响应时间135ms148ms9.6%采集任务平均耗时1.8秒/表1.9秒/表5.6%质量任务平均耗时8.2秒/表8.8秒/表7.3%在可接受范围内。七、稳定性测试中压出的其他问题除了上面这几个我们在多轮稳定性测试中还压出了以下问题问题四内存泄漏导致OOM测试跑到第六天的时候某个采集服务的JVM内存使用率从正常的40%涨到了90%然后触发了Full GC服务卡顿了5分钟大量任务超时。排查手段用jmap导出了堆内存dump文件用MATMemory Analyzer Tool分析发现某个缓存Map一直在膨胀从来没清理过。bash# 导出堆dump jmap -dump:live,formatb,fileheap.hprof pid # 用MAT分析找到最大的对象解决方案给缓存加了个大小限制使用LRULeast Recently Used淘汰策略超过上限就自动淘汰最久未使用的条目。java// 修改前 MapString, Object cache new HashMap(); cache.put(key, value); // 一直往里塞从来不删 // 修改后 CacheString, Object cache Caffeine.newBuilder() .maximumSize(10000) // 最多缓存1万条 .expireAfterWrite(1, TimeUnit.HOURS) // 1小时后自动过期 .build();问题五HDFS小文件堆积SparkSQL作业每跑一次就会在HDFS上生成一些临时文件。七天下来临时文件累积了80多万个小文件NameNode的内存被撑爆了导致整个HDFS集群变慢。解决方案配置Spark作业自动清理临时目录。sqlSET spark.sql.autoBroadcastJoinThreshold104857600; -- 关键是下面这个配置作业结束后自动删除临时文件 SET spark.sql.adaptive.coalescePartitions.enabledtrue;同时增加了一个每日定时任务清理超过3天的临时文件bash# 每天凌晨2点清理HDFS临时文件 hdfs dfs -rm -r -skipTrash /tmp/spark/*/ 2/dev/null八、稳定性测试结论一轮7×24小时的稳定性测试跑下来发现的主要问题问题发现时间严重程度解决方案日志写满磁盘第4天高差点宕机定时清理脚本连接池泄漏第5天中成功率下降代码加finally释放Kafka频繁Rebalance第5天中短暂抖动调大超时参数长事务撑爆UNDO第7天高性能严重衰减优化SQL清理UNDO内存泄漏OOM第6天高服务卡顿限制缓存大小LRUHDFS小文件堆积第7天中影响集群性能自动清理临时文件几个核心经验性能测试看快不快稳定性测试看多久还是这么快。第七天比第一天慢了一倍多这种衰减在短期的性能测试里是发现不了的。75% CPU压力是稳定性测试的黄金标准。太低压不出问题太高系统直接崩溃没法观察。75%刚好让所有组件都工作在接近极限的状态长期运行各种隐藏问题都会暴露。日志清理不是小事。日志写满磁盘是稳定性测试里最高频的问题之一一定要有自动清理机制而且要持续监控磁盘使用率。长事务是性能衰减的最大杀手。一个跑了6小时的COUNT(*)看起来只是慢但它会拖慢整个系统。对大表查询能用统计信息就别用全表扫描。