ifeve.com 南方《JVM 性能调优实战之:使用阿里开源工具 TProfiler 在海量业务代码中精确定位性能代码》

https://blog.csdn.net/defonds/article/details/52598018

多次拉取 JStack,发现很多线程处于这个状态:
    at jrockit/vm/Allocator.getNewTla(JJ)V(Native Method)
    at jrockit/vm/Allocator.allocObjectOrArray(Allocator.java:354)[optimized]
    at java/util/HashMap.resize(HashMap.java:564)[inlined]
    at java/util/LinkedHashMap.addEntry(LinkedHashMap.java:414)[optimized]
    at java/util/HashMap.put(HashMap.java:477)[optimized]
由此怀疑出现上述堆栈的原因可能是 TLA 空间不足
---------------------
:Defonds
来源:CSDN
原文:https://blog.csdn.net/defonds/article/details/52598018

原文地址:https://www.cnblogs.com/paper-file/p/9908492.html

时间: 2024-10-12 13:07:45

ifeve.com 南方《JVM 性能调优实战之:使用阿里开源工具 TProfiler 在海量业务代码中精确定位性能代码》的相关文章

JVM 性能调优实战之:使用阿里开源工具 TProfiler 在海量业务代码中精确定位性能代码

本文是<JVM 性能调优实战之:一次系统性能瓶颈的寻找过程> 的后续篇,该篇介绍了如何使用 JDK 自身提供的工具进行 JVM 调优将 TPS 由 2.5 提升到 20 (提升了 7 倍),并准确定位系统瓶颈:我们应用里静态对象不是太多.有大量的业务线程在频繁创建一些生命周期很长的临时对象,代码里有问题.那么问题来了,如何在海量业务代码里边准确定位这些性能代码?本文将介绍如何使用阿里开源工具 TProfiler 来定位这些性能代码,成功解决掉了 GC 过于频繁的性能瓶颈,并最终在上次优化的基础

JVM 性能调优实战之:一次系统性能瓶颈的寻找过程

玩过性能优化的朋友都清楚,性能优化的关键并不在于怎么进行优化,而在于怎么找到当前系统的性能瓶颈.性能优化分为好几个层次,比如系统层次.算法层次.代码层次...JVM 的性能优化被认为是底层优化,门槛较高,精通这种技能的人比较少.笔者呆过几家技术力量不算弱的公司,每个公司内部真正能够进行 JVM 性能调优的人寥寥无几.甚至没有.如是乎,能够有效通过 JVM 调优提升系统性能的人往往被人们冠以"大牛"."大师"之类的称呼.其实 JVM 本身给我们提供了很多强大而有效的监

Spark&amp;Spark性能调优实战

Spark特别适用于多次操作特定的数据,分mem-only和mem & disk.其中mem-only:效率高,但占用大量的内存,成本很高;mem & disk:内存用完后,会自动向磁盘迁移,解决了内存不足的问题,却带来了数据的置换的消费.Spark常见的调优工具有nman.Jmeter和Jprofile,以下是Spark调优的一个实例分析: 1.场景:精确客户群 对一个容量为300g的客户信息表在spark上进行查询优化,该大宽表有1800多列,有效使用的有20列. 2.优化达到的效果:

PHP 性能分析第三篇: 性能调优实战

注意:本文是我们的 PHP 性能分析系列的第三篇,点此阅读 PHP 性能分析第一篇: XHProf & XHGui 介绍 ,或  PHP 性能分析第二篇: 深入研究 XHGui. 在本系列的 第一篇 中,我们介绍了 XHProf .而在 第二篇 中,我们深入研究了 XHGui UI, 现在最后一篇,让我们把 XHProf /XHGui 的知识用到工作中! 性能调优 不用运行的代码才是绝好的代码.其他只是好的代码.所以,性能调优时,最好的选择是首先确保运行尽可能少的代码. OpCode 缓存 首先

深入理解JVM(6)——JVM性能调优实战

如何在高性能服务器上进行JVM调优:以便充分利用高性能服务器的硬件资源,有两种JVM调优方案. 一.        采用64位操作系统,并为JVM分配大内存 分析:如果JVM中堆内存太小,那么就会频繁地发生垃圾回收,而垃圾回收都会伴随不同程度的程序停顿. a)        优点:扩大堆内存的话可以减少垃圾回收的频率,从而避免程序的停顿.因此,人们自然而然想到扩大内存容量.而32位操作系统理论上最大只支持4G内存,64位操作系统最大能支持128G内存,因此我们可以使用64位操作系统,并使用64位

UIKit性能调优实战讲解

使用微信扫一扫查看全文干货 作者:bestswifter 在使用UIKit的过程中,性能优化是永恒的话题.很多人都看过分析优化滑动性能的文章,但其中不少文章只介绍了优化方法却对背后的原理避而不谈,或者是晦涩难懂而且读者缺乏实践体验的机会.不妨思考一下下面的问题自己是否有一个清晰的认识: 为什么要把控件尽量设置成不透明的,如果是透明的会有什么影响,如何检测这种影响? 为什么cell中的图片,尽可能要使用正确的大小.格式,如果错误会有什么影响,如何检测这种影响? 为什么设置阴影和圆角有可能影响滑动时

Spark&amp;amp;Spark性能调优实战

Spark特别适用于多次操作特定的数据,分mem-only和mem & disk.当中mem-only:效率高,但占用大量的内存,成本非常高;mem & disk:内存用完后,会自己主动向磁盘迁移,攻克了内存不足的问题,却带来了数据的置换的消费.Spark常见的调优工具有nman.Jmeter和Jprofile,下面是Spark调优的一个实例分析: 1.场景:精确客户群 对一个容量为300g的客户信息表在spark上进行查询优化,该大宽表有1800多列.有效使用的有20列. 2.优化达到的

【转】性能调优从哪里入手

说到性能调优,给人的感觉往往都是修炼有成的专家干得事了,对于我们这些菜鸟还是想也不要想了,做好分内事,不出现纰漏就OK了.对于这种观点我表示严肃的否决!那想学习性能调优的童鞋应该从哪里下手呢?接下来就让我们来谈谈关于性能调优你所忽视的一些常识. 一.代码:前文讲过“华为Java编程军规,每季度代码验收标准”这个标准是衡量代码本身的缺陷,也是衡量一个研发人员本身的价值.代码是性能调优中的一粒分子,分子虽小但经过上亿次的分裂也会变成黑洞,所以代码本身的缺陷也是我们性能调优的主因之一. 军规一:[避免

Linux性能调优,从优化思路说起

Linux操作系统是一个开源产品,也是一个开源软件的实践和应用平台,在这个平台下有无数的开源软件支撑,我们常见的apache.tomcat.mysql.php等等,开源软件的最大理念是自由.开放,那么linux作为一个开源平台,最终要实现的是通过这些开源软件的支持,以最低廉的成本,达到应用最优的性能.因此,谈到性能问题,主要实现的是linux操作系统和应用程序的最佳结合. 一.性能问题综述 系统的性能是指操作系统完成任务的有效性.稳定性和响应速度.Linux系统管理员可能经常会遇到系统不稳定.响