性能文章>JVM菜鸟进阶高手之路八(一些细节)>

JVM菜鸟进阶高手之路八(一些细节)原创

2年前
701802

GC 日志问题

查看docker环境的gc日志,发现是下面这种情况,很奇怪,一直怀疑是docker环境那里是否有点问题,并没有怀疑配置,之前物理机上面的gc日志都是正常那种。

image.png

表示很奇怪,后来飞哥告诉我,有没有PrintGCDetails这个参数呀?一看果然,加上之后gc日志就和我们以前看的正常格式一样了。

Xmn 问题

-Xms4g -Xmx4g -Xmn3g 使用cms回收器,查看gc日志,发现一次ygc需要效果大概20s多,平均时间都在10s左右,入下图:

image.png

查看jmap,并且dump拉下来分析都正常 如图:

image.png

image.png

没啥问题啊,觉得特别奇怪,堆还是4G但是xmn去掉了(这里有个误区,以为新老比是1:2(默认) xmn默认就是1.33g 其实不是)查看日志:

image.png

Young现在760M了, Young代并不是一开始到最大值,也是慢慢扩展,但是这块时间的确没有之前那样的ygc需要10几秒了,再次添加-Xmn1.2g(尴尬了,启动不起来)

image.png

飞哥告诉我们JVM参数不能有小数,赶紧修改-Xmn1200m正常了。但是ygc的太频繁。

image.png

想不要这么频繁,修改-Xmn2g,结果意外了:

image.png

继续修改回来-Xmn1200m正常了,就是频率高了点。几分钟快700多次了。

image.png

可以确定的就是回收速度一定要比分配速度快,从这个来看GC情况还算好。

联机事务处理(OLTP)与联机分析处理(OLAP)

  • OLTP:Online Transaction Processing 联机事务处理
  • OLAP:Online Analytical Processing 联机分析处理

OLTP 顾名思义,以业务处理为主。OLAP则是专门为支持复杂的分析操作而设计的,侧重于对决策人员和高层管理人员的决策支持,可以应分析人员的要求快速、灵活地进行大数据量的复杂查询处理,并以一直直观的形式把查询结果提供。

OLTP与OLAP 的主要区别有以下几点:

  1. 所面向的用户和系统:OLTP是面向客户的,由职员或客户进行事务处理或者查询处理。OLAp是向向市场的,由经理、主管和分析人员进行数据分析和决策的。

  2. 数据内容:OLTP系统管理当前数据,这些数据通常很琐碎,难以用于决策。OLAP系统管理大量历史数据,提供汇总和聚集机制,并在不同的粒度级别上存储和管理信息,这些特点使得数据适合于决策分析。

  3. 数据库设计:通常,OLTP采用ER模型和面向应用的数据库设计,而OLAP系统通常采用星型模式或雪花模式和面向主题的数据库设计。

  4. 视图:OLTP系统主要关注一个企业或部门的当前数据,而不涉及历史数据或不同组织的数据。与之相反,OLAP系统常常跨越一个企业的数据库模式的多个版本,OLAP系统也处理来自不同组织的信息,由多个数据源集成的信息。

  5. 访问模式:OLTP系统的访问主要由短的原子事务组成,这种系统需要并发控制和恢复机制。而OLAP系统的访问大部份是只读操作,其中大部份是复杂查询。

  6. 度量:OLTP专注于日常时实操作,所以以事务吞吐量为度量,OLAP以查询吞吐量和响应时间来度量。针对OLTP系统、OLAP系统 jvm调优还是不一样的。

OLAP系统垃圾回收器选择

由于系统配置的是cms(和业务系统一样的配置 OLTP系统)这个应该是吞吐量优先,应该不用cms收集器,修改配置,Xmx4g Xms4G Xmn1300m -XX:+UseParallelGC -XX:+UseParallelOldGC ,关于-XX:+UseParallelGC -XX:+UseParallelOldGC是否可以同时写,

image.png

XX:+UseParallelGC, 新生代ParallelGC回收器,如果老年代不配置,那么老年代串行,只是老年代默认串行而已,再显示老年代UserParallelOldGC, 那老年代就是并行。一起都正常,还没有发现old满gc情况,回头在观察下。
疑惑,感觉xmn这个参数设置很有技巧啊,为什么设置Xmn2g的时候 就会ygc频率的确少了,但是ygc数据长了好几千倍了,为什么设置Xmn1200m或者说Xmn1300m很正常时间都在65ms左右。而且关于YGC真的不好排查,还在实践。希望看见此文章的,如果可以帮助解答疑惑,那么在此表示感谢!!!

分类:标签:
请先登录,感受更多精彩内容
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

不起眼,但是足以让你有收获的JVM内存分析案例
分析 这个问题说白了,就是说有些int[]对象不知道是哪里来的,于是我拿他的例子跑了跑,好像还真有这么回事。点该 dump 文件详情,查看相关的 int[] 数组,点该对象的“被引用对象”,发现所
从一起GC血案谈到反射原理
前言 首先回答一下提问者的问题。这主要是由于存在大量反射而产生的临时类加载器和 ASM 临时生成的类,这些类会被保留在 Metaspace,一旦 Metaspace 即将满的时候,就会触发 Fu
关于内存溢出,咱再聊点有意思的?
概述 上篇文章讲了JVM在GC上的一个设计缺陷,揪出一个导致GC慢慢变长的JVM设计缺陷,可能有不少人还是没怎么看明白的,今天准备讲的大家应该都很容易看明白 本文其实很犹豫写不写,因为感觉没有
协助美团kafka团队定位到的一个JVM Crash问题
概述 有挺长一段时间没写技术文章了,正好这两天美团kafka团队有位小伙伴加了我微信,然后咨询了一个JVM crash的问题,大家对crash的问题都比较无奈,因为没有现场,信息量不多,碰到这类问题我
又发现一个导致JVM物理内存消耗大的Bug(已提交Patch)
概述 最近我们公司在帮一个客户查一个JVM的问题(JDK1.8.0_191-b12),发现一个系统老是被OS Kill掉,是内存泄露导致的。在查的过程中,阴差阳错地发现了JVM另外的一个Bug。这个B
JVM实战:优化我的IDEA GC
IDEA是个好东西,可以说是地球上最好的Java开发工具,但是偶尔也会卡顿,仔细想想IDEA也是Java开发的,会不会和GC有关,于是就有了接下来对IDEA的GC进行调优 IDEA默认JVM参数: -
不起眼,但是足以让你收获的JVM内存案例
今天的这个案例我觉得应该会让你涨姿势吧,不管你对JVM有多熟悉,看到这篇文章,应该还是会有点小惊讶的,不过我觉得这个案例我分享出来,是想表达不管多么奇怪的现象请一定要追究下去,会让你慢慢变得强大起来,
如何通过反射获得方法的真实参数名(以及扩展研究)
前段时间,在做一个小的工程时,遇到了需要通过反射获得方法真实参数名的场景,在这里我遇到了一些小小的问题,后来在部门老大的指导下,我解决了这个问题。通过解决这个问题,附带着我了解到了很多新的知识,我觉得