jvm调优小结

发布时间:2020-07-14 12:08:43 作者:一线运维
来源:网络 阅读:3332

不区分tomcat,resion等应用,主要是针对jvm调优

tomcat家目录下catalina.sh  catalina.bat


从http://unixboy.iteye.com/blog/174173


这个是jvm内存体系结构

http://blog.csdn.net/java2000_wl/article/details/8009362


http://www.360doc.com/content/15/0429/15/7853380_466822446.shtml详细讲解-XX:ParallelGCThreads

学到了很多东西,又加一点点自己的补充和理解。






  1. 堆大小设置
    JVM 中最大堆大小有三方面限制:相关操作系统的数据模型(32-bt还是64-bit)限制;系统的可用虚拟内存限制;系统的可用物理内存限制。32位系统下,一般限制在1.5G~2G;64为操作系统对内存无限制。我在Windows Server 2003 系统,3.5G物理内存,JDK5.0下测试,最大可设置为1478m。
    典型设置:

回收器选择JVM给了三种选择:串行收集器、并行收集器、并发收集器,但是串行收集器只适用于小数据量的情况,所以这里的选择主要针对并行收集器和并发收集器。默认情况下,JDK5.0以前都是使用串行收集器,如果想使用其他收集器需要在启动时加入相应参数。JDK5.0以后,JVM会根据当前系统配置进行判断。

  1. 吞吐量优先的并行收集器
    如上文所述,并行收集器主要以到达一定的吞吐量为目标,适用于科学技术和后台处理等。
    典型配置

  2. 响应时间优先的并发收集器
    如上文所述,并发收集器主要是保证系统的响应时间,减少垃圾收集时的停顿时间。适用于应用服务器、电信领域等。
    典型配置

辅助信息JVM提供了大量命令行参数,打印信息,供调试使用。主要有以下一些:

常见配置汇总


-XX:CMSInitiatingOccupancyFraction

当堆满之后,并行收集器便开始进行垃圾收集,例如,当没有足够的空间来容纳新分配或提升的对象。对于CMS收集器,长时间等待是不可取的,因为在并发垃圾收集期间应用持续在运行(并且分配对象)。因此,为了在应用程序使用完内存之前完成垃圾收集周期,CMS收集器要比并行收集器更先启动。

因为不同的应用会有不同对象分配模式,JVM会收集实际的对象分配(和释放)的运行时数据,并且分析这些数据,来决定什么时候启动一次CMS垃圾收集周期。为了引导这一过程, JVM会在一开始执行CMS周期前作一些线索查找。该线索由 -XX:CMSInitiatingOccupancyFraction=<value>来设置,该值代表老年代堆空间的使用率。比如,value=75意味着第一次CMS垃圾收集会在老年代被占用75%时被触发。通常CMSInitiatingOccupancyFraction的默认值为68(之前很长时间的经历来决定的)。



  1. 堆设置

  2. 收集器设置

  3. 垃圾回收统计信息

  4. 并行收集器设置

  5. 并发收集器设置







四、调优总结

  1. 年轻代大小选择

年老代大小选择

较小堆引起的碎片问题因为年老代的并发收集器使用标记、清除算法,所以不会对堆进行压缩。当收集器回收时,他会把相邻的空间进行合并,这样可以分配给较大的对象。但是,当堆空间较小时,运行一段时间以后,就会出现“碎片”,如果并发收集器找不到足够的空间,那么并发收集器将会停止,然后使用传统的标记、清除方式进行回收。如果出现“碎片”,可能需要进行如下配置:







以下是关于ParallelGCThreads的详解

1.含义

    ParallelGCThreads,表示JVM在进行并行GC的时候,用于GC的线程数,-XX:ParallelGCThreads=43,表示配置GC线程数为43。

2.JVM相关接口

    JVM中,关于ParallelGCThreads的计算代码如下:

unsigned int VM_Version::calc_parallel_worker_threads() {

  unsigned int result;

  if (is_M_series()) {

    // for now, use same gc thread calculation for M-series as for niagara-plus

    // in future, we may want to tweak parameters for nof_parallel_worker_thread

    result = nof_parallel_worker_threads(5, 16, 8);

  } else if (is_niagara_plus()) {

    result = nof_parallel_worker_threads(5, 16, 8);

  } else {

    result = nof_parallel_worker_threads(5, 8, 8);

  }

  return result;

} 

unsigned int Abstract_VM_Version::parallel_worker_threads() {

  if (!_parallel_worker_threads_initialized) {

    if (FLAG_IS_DEFAULT(ParallelGCThreads)) {

      _parallel_worker_threads = VM_Version::calc_parallel_worker_threads();

    } else {

      _parallel_worker_threads = ParallelGCThreads;

    }

    _parallel_worker_threads_initialized = true;

  }

  return _parallel_worker_threads;

}

unsigned int Abstract_VM_Version::calc_parallel_worker_threads() {

  return nof_parallel_worker_threads(5, 8, 8);

}

unsigned int Abstract_VM_Version::nof_parallel_worker_threads(

                                                      unsigned int num,

                                                      unsigned int den,

                                                      unsigned int switch_pt) {

  if (FLAG_IS_DEFAULT(ParallelGCThreads)) {

    assert(ParallelGCThreads == 0, "Default ParallelGCThreads is not 0");

    // For very large machines, there are diminishing returns

    // for large numbers of worker threads.  Instead of

    // hogging the whole system, use a fraction of the workers for every

    // processor after the first 8.  For example, on a 72 cpu machine

    // and a chosen fraction of 5/8

    // use 8 + (72 - 8) * (5/8) == 48 worker threads.

    unsigned int ncpus = (unsigned int) os::active_processor_count();

    return (ncpus <= switch_pt) ?

           ncpus :

          (switch_pt + ((ncpus - switch_pt) * num) / den);

  } else {

    return ParallelGCThreads;

  }

} 

3.计算方法

    上面列出了与ParallelGCThreads计算相关的几个核心接口,其中,最主要关注nof_parallel_worker_threads接口,该接口中给出了计算ParallelGCThreads值的具体算法,具体如下:

    ①如果用户显示指定了ParallelGCThreads,则使用用户指定的值。

    ②否则,需要根据实际的CPU所能够支持的线程数来计算ParallelGCThreads的值,计算方法见步骤③和步骤④。

    ③如果物理CPU所能够支持线程数小于8,则ParallelGCThreads的值为CPU所支持的线程数。这里的阀值为8,是因为JVM中调用nof_parallel_worker_threads接口所传入的switch_pt的值均为8。

    ④如果物理CPU所能够支持线程数大于8,则ParallelGCThreads的值为8加上一个调整值,调整值的计算方式为:物理CPU所支持的线程数减去8所得值的5/8或者5/16,JVM会根据实际的情况来选择具体是乘以5/8还是5/16。

    比如,在64线程的x86 CPU上,如果用户未指定ParallelGCThreads的值,则默认的计算方式为:ParallelGCThreads = 8 + (64 - 8) * (5/8) = 8 + 35 = 43。


推荐阅读:
  1. JVM调优浅谈
  2. 如何实现JVM调优

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

jvm调优小结 j

上一篇:Nginx学习笔记(2)------Nginx日志

下一篇:wxWidgets第六课 EVT_ERASE_BACKGROUND背景擦除事件

相关阅读

您好,登录后才能下订单哦!

密码登录
登录注册
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》