PT环境下Sanity Load Test执行步骤及检查清单咨询

一、执行步骤 #

• 环境校验：确保staging环境的硬件配置、软件版本、系统参数（如JVM参数、数据库配置）与生产环境完全对齐，提前备份环境数据，避免测试数据污染。
• 测试场景定义：聚焦核心业务路径（例：用户登录、商品查询、订单提交），设置目标并发数为生产峰值的30%-50%，测试持续时间控制在15-30分钟（Sanity测试无需长时间压测）。
• 监控前置部署：启动全链路监控：
  • 系统级：开启top、vmstat、iostat实时监控
  • 应用级：启动APM工具（若有）、开启应用DEBUG/INFO级日志
  • 数据库级：开启慢查询日志、连接数监控
• 测试执行：逐步加压（从低并发到目标并发），过程中实时观察监控指标，记录任何异常波动。
• 后测试验证：停止压测后，持续观察10-15分钟，确认系统资源是否回落至基线水平，排查是否有进程崩溃、数据不一致等问题。

二、核心检查清单 #

系统层指标 #

• 磁盘I/O：用iostat -x 1查看磁盘使用率（%util）、读写延迟（await），若%util持续超过80%、await>10ms则存在瓶颈
• 网络状态：用iftop监控带宽占用，ping/traceroute检查服务器间、客户端到服务器的丢包率、延迟，丢包率>1%或延迟>200ms需排查
• 进程健康度：用ps aux排查是否有僵尸进程（Z状态）、异常重启的进程，记录高CPU/内存进程的PID和对应的服务
• 文件句柄：用sysctl fs.file-nr查看系统总文件句柄使用情况，lsof -p <应用PID>检查单个应用的文件句柄占用，避免接近系统上限
• 系统负载：用uptime查看1/5/15分钟负载值，若负载持续超过CPU核心数，说明系统资源饱和

应用层指标 #

• 接口响应时间：统计核心接口的平均响应时间、95/99分位响应时间，需与历史基线对比，若波动超过20%需分析原因
• 错误率：监控接口返回的4xx/5xx错误码，错误率需控制在0.1%以内，重点关注500、502等服务器端错误
• 日志异常：检查应用日志中的报错信息，如数据库连接超时、缓存击穿、第三方API调用失败
• 资源泄漏：停止测试后观察应用内存、文件句柄是否回落至测试前水平，若持续高位则存在泄漏风险
• 依赖服务状态：检查Redis、MQ、第三方服务的可用性、响应延迟，确认依赖服务未成为瓶颈

数据库层指标 #

• 慢查询：导出慢查询日志，分析执行时间超过1s的SQL，排查是否缺少索引、表结构不合理
• 连接数：用show processlist（MySQL）查看当前连接数，确认未接近max_connections上限
• 缓存命中率：检查数据库缓冲池（如InnoDB Buffer Pool）命中率，需保持在95%以上；应用缓存（如Redis）命中率需保持在90%以上
• 锁争用：查看数据库锁状态（如MySQL的show engine innodb status），排查是否存在表锁、行锁阻塞，导致事务超时

内容的提问来源于stack exchange，提问作者Antonio