背景
最近生产环境进行 压测，频发 cpu 超高问题。针对 cpu 频发问题，进行了一波压测分析，解决一些隐藏的问题，
主要是一些工具的 使用和问题的总结
使用工具
- Jprofiler 11.1.4 (11.1.1 版本以下的，不支持 分析 .jfr 文件) （目前新版本 idea 也可以打开 jfr 文件，进行分析）
- Arthas
【 case 一】[数据查询服务 data] CPU 高耗场景，压测分析
数据查询服务，是一个存粹 IO 密集型的操作服务，查询 db 组装返回，无任何cpu 密集型操作
压测配置
在 data 服务中，100 并发进行压测。tps 只达到了 1000 左右，此刻 服务的 cpu 已经达到了 90 %多 ，cpu 也是线性上升的机器配置：20 台 4C8G 虚拟机
当时场景如下
分析：
服务是 IO 密集型服务，不会有太多的 cpu 损耗。这种表现并不正常。从外层接口，并不能分析出来cpu 占用率比较高的点，只能 dump 一些压测现场，进行分析。
操作步骤:
由于晚上，且 无太大流量，直接申请在线上执行操作。且由于目前线上不能支持直接用 jprofiler 直连 远程机器,进行一些现场场景的分析
- 采取 arthas 的 profiler 命令 生成文件 下载到 本地进行分析
profiler 命令支持生成应用热点的火焰图。本质上是通过不断的采样，然后把收集到的采样结果生成火焰图
通过 arthas 进行 jfr 文件的 生成，具体可以看这个profiler --- Arthas 3.5.4 文档,对 cpu 利用率较高的代码和方法进行分析 通过 arthas + jprofiler 进行 cpu 分析 可以查看文档使用arthas+jprofiler做复杂链路分析 · Issue #1416 · alibaba/arthas · GitHub
通过压测过程中，进行 现场获取，生成 jfr 格式 的文件。
下载到本地，然后通过 jprofiler 执行
如下图所示可以看到，大量的 cpu 利用率在这个地方，占用 80% 多
逐步对该顶层方法进行分析，逐步展开，最后发现，高利用率的如下 ，约 37%
打印 info 日志的 JSON.toJSoinString 占用也达到了 2.5 % ，且在代码中有 2 处，总计 4%
通过分析：
发现总体大概 42% 左右，快一半了，cpu 的利用率 被损耗在了这 个地方。
其余的，部分为无侵入调用链 apm 的一些损耗， data 服务 cpu 高的原因已经明确。
改进措施
- 接下来进行 深度 clone 的方法的改造
- 去除一些无用的打印一些无意义的 json 转string
注意： 我们需要吝啬一点，针对资源。一些不小心的，感觉毫无印象的一些 日志打印，json 转换 ，会逐渐的蚕食我们的 性能。
【 case 二 】编排服务 cpu 飙升问题分析
在之前的压测中，已经分析出来，xie.infoq.cn/article/15f...
该服务的 内存被打爆问题，是来自于 组件节点 processor 的 日志上报，大量的上报不及时的日志，长久的停留在内存中。在解决了部分日志带来的大内存问题之后。
再次进行了一次压测配置 20 台 pod 4C8G200 并发，仅压到了 1000 多 tps ，然后就打爆了 cpu 和内存，内存问题已知，
服务分析
该服务，只有一个简单的 rpc 调用和 部分非常简单的 转换，压根不会涉及到 cpu的一些高利用场景
操作步骤
依旧在先开启了该服务的 cpu 分析，进行对应的问题排查。
通过层层的分析，发现 cpu 高耗的节点，都来自于 LogHelper 中的 相关处理，主要就是 JSON.toJsonString 方法后续代码中，针对 JSON.toJSONString 方法慎用
在问题分析出来之后，通过vm 参数关闭了 日志上报功能之后，性能 立刻回复，再次压测如下图
情况乐观，压测 tps 可以提升到 6000，性能依旧没有特别大的影响，相关问题已同步对应团队解决
总结，针对一些表象的原因，应要深入进行一些分析，排查出来具体的一些问题，做到心里有底写代码吝啬一些，若非必要，不用去放一些额外处理时长进行一些测试和分析。用好工具
善假于物，保障服务长久可用