咨询热线:

网赌秒速快艇是真的吗 > 参数设置 >

jvm常用参数设置 专题

2019-08-04 21:27 来源: 震仪

  gauge.*:HTTP请求的性能指标之一,它主要用来反映一个绝对数值。比如上面示例中的gauge.response.hello: 5,它表示上一次hello请求的延迟时间为5毫秒。

  counter.*:HTTP请求的性能指标之一,它主要作为计数器来使用,记录了增加量和减少量。如上示例中counter.status.200.hello: 11,它代表了hello请求返回200状态的次数为11。

  来传入JVM,传入的参数作为system的property。因此在程序中可以通过下面的语句获取参数值:

  JVM自定义参数可用来在集群环境区分当前class运行在哪个JVM上,可以达到让某个class只在某个指定的JVM上运行,避免多个JVM同时运行,出现混乱。

  其一是标准参数(-),所有的JVM实现都必须实现这些参数的功能,而且向后兼容;

  其二是非标准参数(-X),默认jvm实现这些参数的功能,但是并不保证所有jvm实现都满足,且不保证向后兼容;

  其三是非Stable参数(-XX),此类参数各个jvm实现会有所不同,将来可能会随时取消,需要慎重使用;

  输出jvm载入类的相关信息,当jvm报告说找不到类或者类冲突时可此进行诊断。

  -Xms512m 设置JVM促使内存为512m。此值可以设置与-Xmx相同,以避免每次垃圾回收完成后JVM重新分配内存。

  -Xmn200m:设置年轻代大小为200M。整个堆大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m,所以增大年轻代后,将会减小年老代大小。此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8。

  设置每个线以后每个线M,以前每个线K。更具应用的线程所需内存大小进行调整。在相同物理内 存下,减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的,不能无限生成,经验值在3000~5000左右。

  与-verbose:gc功能类似,只是将每次GC事件的相关情况记录到一个文件中,文件的位置最好在本地,以避免网络的潜在问题。

  用-XX作为前缀的参数列表在jvm中可能是不健壮的,SUN也不推荐使用,后续可能会在没有通知的情况下就直接取消了;但是由于这些参数中的确有很多是对我们很有用的,比如我们经常会见到的-XX:PermSize、-XX:MaxPermSize等等;

  1、堆的大小可以通过 -Xms 和 -Xmx 来设置,一般将他们设置为相同的大小,目的是避免在每次垃圾回收后重新调整堆的大小,比如 -Xms=2g -Xmx=2g 或者 -Xms=512m -Xmx=512m

  2、年轻代大小可以通过 -Xmn 来设置,比如-Xmn=2g 或者 -Xmn512m,此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8

  如果同时指定了NewRatio和NewSize,你应该使用更大的那个。于是,当堆空间被创建时,你可以用过下面的表达式计算初始新生代空间的大小:

  问题得到解决。当JVM发生内存溢出的时候,会在C:/下打印出heap dump

  ParallelGCThreads表示并行的线,一般是cpu的核个数,当核个数大于8时可能不是很适用;

  开发、应用中老是会遇到OutOfMemory异常,而且常常是过一段时间内存才被吃光,这里可以利用java heap dump出jvm内存镜像,然后再对其进行分析来查找问题。

  本地部署时抛出异常g.OutOfMemoryError:GC overhead limit exceeded导致服务起不来,查看日志发现加载了太多资源到内存,本地的性能也不好,gc时间消耗的较多。解决这种问题两种方法是,增加参数,-XX:-UseGCOverheadLimit,关闭这个特性,同时增加heap大小,-Xmx1024m。坑填了,but why?

  GC overhead limt exceed检查是Hotspot VM 1.6定义的一个策略,通过统计GC时间来预测是否要OOM了,提前抛出异常,防止OOM发生。Sun 官方对此的定义是:“并行/并发回收器在GC回收时间过长时会抛出OutOfMemroyError。过长的定义是,超过98%的时间用来做GC并且回收了不到2%的堆内存。用来避免内存过小造成应用不能正常工作。“

  听起来没啥用...预测OOM有啥用?起初开来这玩意只能用来Catch住释放内存资源,避免应用挂掉。后来发现一般情况下这个策略不能拯救你的应用,但是可以在应用挂掉之前做最后的挣扎,比如数据保存或者保存现场(Heap Dump)。

  而且有些时候这个策略还会带来问题,比如加载某个大的内存数据时频繁OOM。

  假如你也生产环境中遇到了这个问题,在不知道原因时不要简单的猜测和规避。可以通过-verbose:gc -XX:+PrintGCDetails看下到底什么原因造成了异常。通常原因都是因为old区占用过多导致频繁Full GC,最终导致GC overhead limit exceed。如果gc log不够可以借助于JProfile等工具查看内存的占用,old区是否有内存泄露。分析内存泄露还有一个方法-XX:+HeapDumpOnOutOfMemoryError,这样OOM时会自动做Heap Dump,可以拿MAT来排查了。还要留意young区,如果有过多短暂对象分配,可能也会抛这个异常。

  日志的信息不难理解,就是每次gc时打条日志,记录GC的类型,前后大小和时间。举个例子。

Copyright © 2002-2019 网赌秒速快艇是真的吗 版权所有