结合项目说下压测/调优

项目压测，CPU 占用比较大，除了测试服务器本身的性能影响外，还存在项目本身的问题。这是服务器的配置：

4 core, 8G, 磁盘 50g，作为一个高峰期并发不到 1000 的项目，总的来说这个配置还能用。然后并发刚到 30，就这样了：

最下面两条的是两台服务器内存。粉色的是项目所在服务器的 CPU，蓝色是 DB CPU，项目占用 CPU 飙的太狠，所以展开调查。

压测调优步骤

压测，将 ramp up 时间弄得稍微长一点。项目是 Docker 服务，JDK 版本 1.8。

  1. docker exec -it id bash：进入容器。需要进入容器操作 jstack 命令
  2. jps -l：查看 Java 服务 PID，当然容器内部就一个服务包和 OpenJDK
  3. jstack -l pid >> /opt/xxx.txt：将堆栈信息打出来
  4. 通过 jstat -gcutil pid 查看 M 的值，即 MetaSpace 区使用率
  5. 通过 jstat -gc pid 2s(间隔时间) 3(持续次数) 命令查看 MU/MC 即 Meta 区的使用率
  6. 使用 jstat -gccause pid 观察 CMS FGC
  7. 通过 jinfo pid 得到具体信息
  8. 通过 jinfo -flag <参数> pid 得到此参数信息

利用 GCeasy 分析堆栈信息

GCeasy: 利用好这个网站，这个网站可以将你的堆栈信息解压并分析，基本堆栈信息里就四种状态：WAITING、TIME_WAITING、RUNNABLE、BLOCKED。

  • RUNNABLE 属于正常信息，可以忽略
  • 如果 WAITING 和 TIME_WAITING 的信息过多也需要注意，这个是否正常就要结合场景看下了
  • 最后是 BLOCKED，BLOCKED 是阻塞状态的信息。这种是不正常的，一定要解决的

这次项目压测遇到的就是这种问题。项目延伸用了 Prometheus 监控，里面写的一个拦截器出现延迟加载的现象。最后处理掉了，解决了此次问题。当然还有些 waiting 的，是一个验证类，每次请求都重新构建一次，把它提出来之后 log 没这种提示了。

这是 GCeasy 的网址：https://gceasy.io/，选 tool，把堆栈信息日志打成 zip 格式，点 analyze，它会自动解析那些日志。