当前位置: 首页 > jvm调优
  • 整个集群fgc严重,导致无法为用户提供服务,是由于机器数和qps下其实已经到达瓶颈,稍微的rt或qps的波动都有可能导致整集群崩盘。要预防这种case的另外一个更好的做法还是保持一定频率压测获得应用的单机qps能力,并做相应的限流,确保整体qps达到一定的水位后就扩容。

    阅读全文
    Java 134 人阅读 抢沙发
  • 采用Parallel GC的情况下,当YGC触发时,会有两个检查:1、在YGC执行前,min(目前新生代已使用的大小,之前平均晋升到old的大小中的较小值) > 旧生代剩余空间大小 ? 不执行YGC,直接执行Full GC : 执行YGC;2、在YGC执行后,平均晋升到old的大小 > 旧生代剩余空间大小 ? 触发Full GC : 什么都不做。

    阅读全文
    Java 561 人阅读 抢沙发 , , , , ,
  • 根据多次排查Java Heap外内存泄露的问题,目前的经验为:先查查看有没有错误使用Inflater和Deflater,如有则基本就搞定了;多执行几次jmap -histo:live,看看内存会不会下降,如果会的话,多数和GC的bug有关;perftools,对调用次数的那列进行排序(pprof –text … | sort -n -r -k4),如果看到是Unsafe_Allocate比较多,且为server端应用,则通常说明是哪个地方分配了Direct ByteBuffer,但来不及释放引用,然后嘛,就是用btrace跟踪下看看谁干的,分析原因。

    阅读全文
    Java 558 人阅读 抢沙发 , , , ,
  • 某应用GC频繁的问题原因:由于平均晋升的大小一直 > 旧生代的剩余空间(因为每次FGC后旧生代都只有300多M是空余的,这个在这个应用中是正常的),导致每次YGC的时候悲观策略一直触发,于是看到的就是频繁Full GC了。从这个Case来看,对于需要Cache比较多内容的场景而言(尤其是启动时既要加载的),还是要给old留有一定的空间,否则悲观策略就要发威了.

    阅读全文
    Java 570 人阅读 抢沙发 , , , , , , , ,
  • 某应用出现启动后集群中部分node成功,部分node失败原因为File.listFiles最后会调用到readdir函数,而这个函数返回的文件列表是按inode number排序的,因此在每台linux机器上确实有可能不同,当一个目录下有两个jar中有相同名字但不同内容的class时,就悲催了,一个保护做法是在实现classloader时,最好是先对listFiles排下序,避免集群中node出现表现不一致的问题。

    阅读全文
    Java 394 人阅读 抢沙发 , , ,
  • 在查看String.intern的一些变化时,突然想到了这个case,发现在这个case的根本原因上,判断错误了,频繁抛NoSuchMethodException并不是造成cpu us变化的原因,而是因为method = clazz.getMethod(methodName, parameterTypes);这行代码,对应的Class.getMethod中会执行methodName.intern(),而这个case中,methodName会跟着请求而动态的变化,所以导致了位于perm gen的StringTable中的String不断的增加,而StringTable的size默认为1009,String太多的话会导致hash冲突严重,链表长度过长,导致了每次String.intern时去链表里遍历很耗cpu。

    阅读全文
    Java 463 人阅读 抢沙发 , , ,