6. 性能瓶颈的定位-济南python培训负责整理
很明显,上述 JVM 调整没有从根本上解决性能问题,我们还没有真正定位到系统性能瓶颈。
6.2. 找到性能瓶颈
事情到了这里,已经不难得出当前系统瓶颈就是频繁 GC.

为何会如此频繁 GC 呢?继续看 JStack,发现这两个互相矛盾的现象:
一方面 GC Worker 线程在拼命 GC,但是 GC 前后效果不明显,已用堆内存始终降不下来;
另一方面大量 ExecuteThread 业务处理线程处于 alloc_enqueue_allocation_and_wait_for_gc 的 native_blocked 阻塞状态。
此外,停止压测以后,查看已用堆内存大小,也就几百兆,不到分配堆内存的 1/10.
这说明了什么呢?这说明了我们应用里没有内存泄漏、静态对象不是太多、有大量的业务线程在频繁创建一些生命周期很长的临时对象。
很明显还是代码里有问题。那么这些对象来自哪里?如何在海量业务代码里边准确定位这些性能代码?也就是说如何利用 JVM 调优驱动代码层面的调优?请参考博客《JVM 性能调优实战之:使用阿里开源工具 TProfiler 在海量业务代码中精确定位性能代码》,使用 TProfiler 我们成功找到了代码里边导致 JVM 频繁 GC 的元凶,并最终解决掉了这个性能瓶颈,将 TRT 降到了 0.5,TPS 提升至 100 +.
以上就是济南python培训给大家做的内容详解,更多关于python的学习,请继续关注济南python培训