1.吞吐量到上限时系统负载未到阈值：一般是被测服务分配的系统资源过少导致的。测试过程中如果发现此类情况，可以从ulimit、系统开启的线程数、分配的内存等维度定位问题原因
2.CPU的us和sy不高，但wa很高：如果被测服务是磁盘IO密集型型服务，wa高属于正常现象。但如果不是此类服务，最可能导致wa高的原因有两个，一是服务对磁盘读写的业务逻辑有问题，读写频率过高，写入数据量过大，如不合理的数据载入策略、log过多等，都有可能导致这种问题。二是服务器内存不足，服务在swap分区不停的换入换出。
3.同一请求的响应时间忽大忽小：在正常吞吐量下发生此问题，可能的原因有两方面，一是服务对资源的加锁逻辑有问题，导致处理某些请求过程中花了大量的时间等待资源解锁；二是Linux本身分配给服务的资源有限，某些请求需要等待其他请求释放资源后才能继续执行。
4.内存持续上涨：在吞吐量固定的前提下，如果内存持续上涨，那么很有可能是被测服务存在明显的内存泄漏，需要使用valgrind等内存检查工具进行定位
5.某次压⼒测试，CPU/内存/⽹络 等指标表现良好，但响应 耗时⾮常久 监控查看磁盘 IO 异常，追查发现 ⽇志级别 设置为 Debug，⼤量 ⽇志打印拖累性能 同步⽇志，可能是潜在的性能杀⼿
6.某次压⼒测试，同样并发 TPS，但前期性能良好，后期数 据库 CPU 飙升 压测会产⽣⼤量级的数据，数据增⻓会带来性能的损耗 压测数据不合理，导致统⼀设备关联多个⽤户，服务端不做限制 的 in 查询 不合理分⻚，未做⻚数 limit，导致将数据库新增数据全部查询
7.某次稳定性测试，如果 HTTP ⼊⼝流量仅百 QPS，但下 游 RPC 服务打挂 商户列表，For 循环调⽤下游解决，导致请求数百倍扩⼤
8.某次查询接口压力测试,响应时间很长，cpu,内存正常，其中有张大数据的表的某个组合查询未加组合索引导致查询时间过长