开始之前 在开始之前先记录一个我碰到的jvm调优的坑.那就是… 为啥我配置到idea64exe.vmoptions中的参数没有生效??? 由于之前一直是在mac上开发,本地开发时当需要优化jvm参数的时候直接去idea的安装目录里修改idea.vmoptions就可以了,换到windows以后想当然的也这么改,但是发现似乎我配置的参数并没有生效, what‘s the f***?探索了一番终于发现了问题所在. windows是基于用户登录的,idea会为每个用户在当前用户根目录下创建一份配置信息

简介 jdk8的元空间的初始大小是21M,如果启动后GC过于频繁,请将该值设置得大一些. 更多Meatspace内容见<Metaspace 之一:Metaspace整体介绍(永久代被替换原因.元空间特点.元空间内存查看分析方法)> 如果应用启动时,FGC出现了,可能是由于metaspace导致,例如: 从JDK8开始,永久代(PermGen)的概念被废弃掉了,取而代之的是一个称为Metaspace的存储空间.Metaspace使用的是本地内存,而不是堆内存,也就是说在默认情况下Metaspac

https://mp.weixin.qq.com/s/1VP7l9iuId_ViP1Z_vCA-w 某天早上,毛老师在群里问「cat 上怎么看 gc」. 好好的一个群 看到有 GC 的问题,立马做出小鸡搓手状. 之后毛老师发来一张图. 老年代内存占用情况 图片展示了老年代内存占用情况. 第一个大陡坡是应用发布,老年代内存占比下降,很正常. 第二个小陡坡,老年代内存占用突然下降,应该是发生了老年代 GC. 但奇怪的是,此时老年代内存占用并不高,发生 GC 并不是正常现象. 于是,毛老师查看了 GC

-Xmx4G 设置堆的最大内存大小为4GB,也可通过-XX:MaxHeapSize=4GB进行设置 -Xms256m 设置堆的初始内存大小为256兆,如果未设置此选项,则初始大小将设置为新生代和年老代分配的内存大小总和,也可通过-XX:InitialHeapSize=256m进行设置 -Xmn256m 设置新生代的初始内存大小和最大内存大小为256兆,也可通过-XX:NewSize=256m设置新生代初始内存大小.-XX:MaxNewSize=256m设置新生代最大内存大小 -Xss256k 设

前言 昨天谢照东大神在群里提出一个问题:怎么查看Metaspace里具体包含的是什么,起因是他的某个服务设置了-XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=512m,但是通过jstat -gcutil pid查看M的值为98(M的=MU/MC),即Metaspace区的使用量达到了512m*98%.遗憾的是,这个推算是错误的: 推理 以笔者测试环境上某个服务为例,配置了-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize

有的同学虽然写了一段时间 Java 了,但是对于 JVM 却不太关注.有的同学说,参数都是团队规定好的,部署的时候也不用我动手,关注它有什么用,而且,JVM 这东西,听上去就感觉很神秘很高深的样子,还是算了吧. 没错,部署的时候可能用不到你亲自动手,但是出现问题了怎么办,难道不用你解决问题吗,如果对 JVM 了解不够的话,有些问题可能排查起来就很费力,或者根本无法解决. 本篇以 JDK Hotspot 8 为背景,介绍一下 JVM 的常用参数.建议你在做一些小项目.小 demo 的时候,也把这些

前提 最近由于系统业务量比较大,从生产的GC日志(结合Pinpoint)来看,需要对部分系统进行GC调优.但是鉴于以往不是专门做这一块,但是一直都有零散的积累,这里做一个相对全面的总结.本文只针对HotSpot VM也就是Oracle Hotspot VM或者OpenJDK Hotspot VM,版本为Java8,其他VM不一定适用. 什么是GC(Garbage Collection) Garbage Collection可以翻译为"垃圾收集" -- 一般主观上会认为做法是:找到垃圾,

1.背景 最近有个同学说他的服务刚启动就收到两次 Full GC 告警, 按道理来说刚启动,对象应该不会太多,为啥会触发 Full GC 呢? 带着疑问,我们还是先看看日志吧,毕竟日志的信息更多. 2.日志 可以看到,其实是两次 CMS GC(监控对 Full GC 和 Old GC 不分).但是你会发现一个奇怪的现象,咦,"CMS-initial-mark: 0K(3222528K)" 怎么 Old Gen 对象使用空间大小为 0,细想服务刚启动,Old Gen 为 0 也算正常,但

FGC----jmap -histo:live导致 线上某服务的老年代配置了CMS,但却在gc.log发现连续Full GC的问题.JVM参数配置如下: -XX:+UseCMSInitiatingOccupancyOnly-XX:CMSInitiatingOccupancyFraction=68 参数的意义是:在老年代到68%的时候,会触发一次CMS GC,应该是出现类似如下的日志: T20:10:37.803+0800: 3246087.559: [CMS-concurrent-mark-st

官方文档 堆参数: -Xms: 堆的初始值,例如 -Xmx2048,初始堆大小为 2G -Xmx: 堆的最大值,例如 -Xmx2048M,允许最大堆内存 2G -Xmn: 新生代大小 -XX:SurvivorRatio:Eden 区所占比例,默认是 8,也就是 80%,例如 -XX:SurvivorRatio=8 最好将 -Xms 和 -Xmx 的值设置成一样的值,这样做是为了防止随着堆空间使用量增加,会动态的调整堆空间大小,有一定的性能损耗,不如开始就设置成相同的值,来规避性能损失. 栈参数:

堆内存分配:JVM初始分配的内存由-Xms指定,默认是物理内存的1/64JVM最大分配的内存由-Xmx指定,默认是物理内存的1/4默认空余堆内存小于40%时,JVM就会增大堆直到-Xmx的最大限制:空余堆内存大于70%时,JVM会减少堆直到 -Xms的最小限制.因此服务器一般设置-Xms.-Xmx相等以避免在每次GC 后调整堆的大小.对象的堆内存由称为垃圾回收器的自动内存管理系统回收. JDK8+移除了Perm,引入了Metapsace JDK 1.8 的对 JVM 架构的改造将类元数据放到本地

    概述 metaspace,顾名思义,元数据空间,专门用来存元数据的,它是jdk8里特有的数据结构用来替代perm,这块空间很有自己的特点,前段时间公司这块的问题太多了,主要是因为升级了中间件所致,看到大家讨论来讨论去,看得出很多人对metaspace还是模棱两可,不是很了解它,因此我觉得有必要写篇文章来介绍一下它,解开它神秘的面纱,当我们再次碰到它的相关问题的时候不会再感到束手无策. 为什么会有metaspace metaspace的由来民间已有很多传说,不过我这里只谈我自己的理解,因为

本文转载自JVM学习--元空间(Metaspace) 从方法区(PermGen)到元空间(Metaspace) 方法区(PermGen) JDK1.8以前的HotSpot JVM有方法区,也叫永久代(permanent generation). 方法区用于存放已被虚拟机加载的类信息.常量.静态变量,即编译器编译后的代码. 方法区是一片连续的堆空间,通过-XX:MaxPermSize来设定永久代最大可分配空间,当JVM加载的类信息容量超过了这个值,会报OOM:PermGen错误. 永久代的GC是和

背景: 原先的物理机环境多是若干块物理磁盘经过RAID卡进行了RAID5之后的虚拟磁盘组,这样我们在操作系统内看到的也就是一块完整的磁盘.我们会在上面进行分区,然后格式化后以便使用. Figure 1这个时候的磁盘看起来一般会是这样的 这种磁盘结构使用了分区进行了存储结构的规划,但是在虚拟化环境中,这样的磁盘结构会给每个独立分区进行扩容带来各种不便,比如我们只能相对方便一些的对E盘进行扩充,而C盘和D盘的扩充就会变得非常麻烦. 思路变更: 有了上面诸多不便,在P2V之后的虚拟化环境中我们可以通过

打算给系统装一个oracle,发现磁盘空间不足.在安装系统的时候我选择的是自动分区,系统就会自动以LVM的方式分区.为了保证系统后期的可用性,建议所有新系统安装都采用LVM,之后生产上的设备我也打算这样做. 参于LVM基本介绍与常用命令请参考:http://www.cnblogs.com/jackruicao/p/6258812.html LVM结构图 扩容之前的磁盘状况 [root@localhost ~]# df -h 文件系统             容量 已用 可用已用%%挂载点 /de

VMware下对虚拟机Ubuntu14系统所在分区sda1进行磁盘扩容 一般来说,在对虚拟机里的Ubuntu下的磁盘进行扩容时,都是添加新的分区,而并不是对其系统所在分区进行扩容,如在此链接中http://www.cnblogs.com/yiru/archive/2012/11/15/2770968.html 就是添加了新的分区.但是我们平时自动安装一些软件或者库,都会自动安装在系统所在分区/dev/sda1里面,很不方便,今天查了相关资料,找到一种可以扩充/dev/sda1的方法,顺便在此记录

需求: 将3个节点的Vertica集群扩容,额外增加3个节点,即扩展到6个节点的Vertica集群. 实验环境: RHEL 6.5 + Vertica 7.2.2-2 步骤: 1.三节点Vertica集群环境创建 2.模拟创建业务最小测试用例 3.集群扩容前准备 4.集群扩容:增加3个节点到集群 Reference 1.三节点Vertica集群环境创建 三节点IP地址和主机名规划: 192.168.56.121 vnode01 192.168.56.122 vnode02 192.168.56.

环境:RHEL 6.5 + GI 11.2.0.4 + Oracle 11.2.0.4 1.确认磁盘权限正确 2.图形界面配置 3.启用asmca配置 4.修改磁盘组rebalance power级别 5.监控磁盘组rebalance完成情况 1.确认磁盘权限正确 如果是RAC,需要确认各个节点都认出磁盘,且权限正确. 一般磁盘是grid:asmadmin属主,660权限. 2.图形界面配置 直接使用VNC,稳定: 或者使用Secure CRT + Xmanager4 passive模式 需要注

当底层实现涉及到扩容时,容器或重新分配一段更大的连续内存(如果是离散分配则不需要重新分配,离散分配都是插入新元素时动态分配内存),要将容器原来的数据全部复制到新的内存上,这无疑使效率大大降低. 加载因子的系数小于等于1,意指  即当 元素个数 超过 容量长度*加载因子的系数 时,进行扩容. 另外,扩容也是有默认的倍数的,不同的容器扩容情况不同. List 元素是有序的.可重复 ArrayList.Vector默认初始容量为10 Vector:线程安全,但速度慢 底层数据结构是数组结构 加载因子为

2016年12月29日14:29:27 参考原文:http://jingyan.baidu.com/article/90808022a6c6b7fd91c80fc8.html 在不损坏磁盘的情况下给某盘扩容,有一个原则: 此处,自己总结为[相邻向右扩]或者[相邻向下扩] 比如给D盘扩容,那就只能从与它相邻的磁盘着手,比如E盘紧邻着D盘,而且在D盘的下一个盘符(或右侧)位置, 图中显示的是F盘在D盘右侧,这跟我个人电脑有关,不过没关系,,意思知道就好了!!! 所以,要给D盘扩容的话,必须先删除它的