性能测试之资源指标异常排查思路

性能测试过程中的服务器资源情况通常为 CPU、内存、磁盘IO、网络 IO 这四项基本且也是最核心的资源作为服务器性能指标衡量的标准。 本次基于实践过程中给大家分享下遇到问题时的排查思路。

一、CPU 利用率高

1. 死循环导致 CPU 耗尽。

    当一个线程陷入死循环后，哪怕循环体内只是一个最简单的逻辑，也会造成 cpu 一个核心的满负荷运行。 此时我们通过 top-Hp 和进程 ID 观察是否有一直为 100%，这种就很有可能该线程陷入死循环，此时需要取抓线程 dump（gcore 命令），如果发现该线程的栈顶方法一直都是 FunctionA，那么就说明是 FunctionA 方法内部触发了死循环。

2. 爬栈

      当 cpu 热点方法出现 getStackTraceElement 方法，需要根据调用栈来分析是什么原因导致爬栈，爬栈通常是由于日志组件或者连接池组件的参数设置问题。

3. 频繁抛出异常导致 CPU 消耗高

      表现在 CPU 热点方法中出现了 fillnStackTrace 方法，抛异常时会获取堆栈信息，影响系统性能，需要针对性解决异常原因。 或者异常在无法解决的时候，可以通过在 jvm 中添加-XX:+OmitStackTraceInFastThrow 参数来改善性能损耗。

4. 加密和解密

     加密和解密存在高 cpu 消耗时，可以考虑将加解密做成独立的服务。 这样可以避免加解密与其他业务逻辑的 cpu 资源争用，更方便对加解密服务进行横向的扩展。

5. 频繁读取网卡 IP 

    对于频繁读取网卡 ip 导致的高 cpu 消耗，可以考虑将 ip 缓存至本地内存。

二、内存

1. 内存增长快，GC 频繁

    针对这种情况如下解决方式：

     a. 减少对象的冗余属性，将对象轻量化；

     b. 减少不必要的临时对象的产生；

     c. 适当扩大堆内存，因为 GC 频繁除了与对象大小，对象分配频率有关意外，还与对象的生命周期有关，如果能让 GC 发生的更晚一些，可能会有更多的对象超出他们的生命周期，成为垃圾对象，从而使 GC 的效果更佳，能回收更多的空闲内存，而每次 GC 回收效果越好，GC 频率下降越明显。

2. 内存泄漏

    这种情况扩大堆内存也无法根治问题，建议在 JVM 参数重添加：HeapDumpOnOutOfMemoryError，一旦发生 OOM，JVM 会自动保留内存的 Dump 文件，随后通过 Dump 文件分析找出内存泄漏的原因。

三、磁盘 IO

1. 写操作多

     当日志内容过大，日志级别较低且频繁写日志的情况下，建议选择合适的日志级别，通常为 Info，必要时可以设置 warn 或者 error。 日志建议只用记录关键信息。

2. 读其他业务文件

     例如上传或者下载接口，建议用 NIO 替代 IO，必要时可以将文件内容缓存起来。

四、网络 IO

通常内网的网络瓶劲出现的概率不高，需要注意如下可能产生网络io 瓶劲的情况：

a. 云服务的带宽限制；

b.异地多机房之间会走专线，可能会导致网络带宽瓶颈；

c. 网卡积压问题

建议：性能测试过程必须要在内网下进行