技术-技术方案优化策略--JVM调优
来源:互联网 发布:大富豪3.29全套源码 编辑:程序博客网 时间:2024/06/01 10:28
什么时候调?
通过监控系统(如没有现成的系统,做一个简单的上报监控系统)上对一些机器关键指标(gc time、gc count、各个分代的内存大小变化、机器的Load值与CPU使用率、JVM的线程数等)的监控报警,也可以看gc log和jstat等命令的输出,再结合线上JVM进程服务的一些关键接口的性能数据和请求体验,基本上就能定位出当前的JVM是否有问题,以及是否需要调优。
怎么调?
- 如果发现高峰期CPU使用率与Load值偏大,这个时候可以观察一些JVM的thread count以及gc count(可能主要是young gc count),如果这两个值都比以往偏大(也可以和一个历史经验值作对比),基本上可以定位是young gc频率过高导致,这个时候可以通过适当增大young区大小或者占比的方式来解决;
- 如果发现关键接口响应时间很慢,可以结合gc time以及gc log中的stop the world的时间,看一下整个应用的stop the world的时间是不是比较多。如果是,可能需要减少总的gc time,具体可以从减小gc的次数和减小单次gc的时间这两个维度来考虑,一般来说,这两个因素是一对互斥因素,我们需要根据实际的监控数据来调整相应的参数(比如新生代与老生代比值、eden与survivor比值、MTT值、触发cms回收的old区比率阈值等)来达到一个最优值;
- 如果发生full gc或者old cms gc非常频繁,通常这种情况会诱发STW的时间相应加长,从而也会导致接口响应时间变慢。这种情况,大概率是出现了“内存泄露”,Java里的内存泄露指的是一些应该释放的对象没有被释放掉(还有引用拉着它)。那么这些对象是如何产生的呢?为啥不会释放呢?对应的代码是不是出问题了?问题的关键是搞明白这个,找到相应的代码,然后对症下药。所以问题的关键是转化成寻找这些对象。怎么找?综合使用jmap和MAT,基本就能定位到具体的代码;
0 0
- 技术-技术方案优化策略--JVM调优
- 技术-技术方案优化策略--代码层面
- 技术-技术方案优化策略--数据库层面
- 技术-技术方案优化策略--缓存层面
- 技术-技术方案优化策略--异步
- 技术-技术方案优化策略--NoSQL
- 技术-技术方案优化策略--监控
- 技术-技术方案优化策略--多线程与分布式
- JVM优化技术
- JVM优化技术
- ARM 程序设计优化策略与技术
- ARM 程序设计优化策略与技术
- ARM 程序设计优化策略与技术
- [转]ARM程序设计优化策略与技术
- ARM 程序设计优化策略与技术
- ARM 程序设计优化策略与技术
- 数据库 SQL 查询技术的优化策略
- Web技术中心代码规范-优化方案
- java 操作给定的二叉树,将其变换为源二叉树的镜像。
- oracle 临时表 with as 写法
- EasyUI所有插件的取值方式
- java内存回收
- 【Spring】Spring容器获取Bean
- 技术-技术方案优化策略--JVM调优
- js事件绑定,事件流,事件代理的一些理解
- Android WebView 与 javascript交互
- Python2.7安装Numpy库、SciPy库、Matplotlib库,各种全解
- Spring是如何管理Bean
- Java 中使用递归遍历文件目录
- Hadoop系列之Aggregate用法
- 使用Jackson和artTemplate来实现List-->json-->html之间的整体转换
- 【项目经验】Java web 页面跳转中文乱码