[讨论] JVM在大内存服务器上怎么充分利用硬件资源
 |
shuhucy
2012-12-04
1、在大内存服务器上（比如32G），JVM怎么充分利用内存了？
单机多集群？单JVM,大的堆内存？或者其他？ 2、假如采用设置大的堆内存，比如（20G以上），怎么控制FULL GC的发生时间及频率，以避免FULL GC时对应用造成停顿？ 单独任务晚上跑System.gc? 求讨论 |
 |
xm_king
2012-12-10
shuhucy 写道 1、在大内存服务器上（比如32G），JVM怎么充分利用内存了？
单机多集群？单JVM,大的堆内存？或者其他？ 2、假如采用设置大的堆内存，比如（20G以上），怎么控制FULL GC的发生时间及频率，以避免FULL GC时对应用造成停顿？ 单独任务晚上跑System.gc? 求讨论 目前通用的解决办法，还是单机多集群。 |
 |
ol_beta
2012-12-10
xm_king 写道 shuhucy 写道 1、在大内存服务器上（比如32G），JVM怎么充分利用内存了？
单机多集群？单JVM,大的堆内存？或者其他？ 2、假如采用设置大的堆内存，比如（20G以上），怎么控制FULL GC的发生时间及频率，以避免FULL GC时对应用造成停顿？ 单独任务晚上跑System.gc? 求讨论 目前通用的解决办法，还是单机多集群。 同意，一般都是开几个虚拟机，然后集群。 |
|
shuhucy
2012-12-17
那就是目前直接配置单机大内存并没有很多的实际应用，配置单机大内存的主要问题在什么地方了？
单机多集群，目前主要是配置32位JDK的好，还是64未JDK的好？ |
 |
david.org
2012-12-27
这贴子就是热门讨论？
|
|
runfriends
2012-12-28
64位比32位稍慢，但是内存吞吐量更大。
还是建议使用64位，至少硬件和软件上不会有内存的限制，内存不够用了，增加内存就可以了。 尽量不要调用System.gc()，它会触发fullgc，而fullgc的频率应该是尽量降低的。尽管有些第三方库调用了它，还是不推荐在应用逻辑或业务逻辑内调用它。 如果重视实时性，建议分配较小的堆，单机运行多个jvm进程。采用标记清除算法，并打开内存压缩开关，指定gc线程数最多是cpu核心数，使用并行回收算法回收年轻代，年轻代尽量大，保证绝大多数对象都在年轻代回收，适当增加对象在幸存区的复制次数，减少fullgc次数和降低fullgc造成的停顿。注意控制PermGen大小，可通过反复测试找到整个应用使用的最大PermGen值，最终确定的值只需要比测试时验证的值稍大即可。适当减少线程栈内存尺寸，增加每进程可支持的线程数。 如果重视吞吐量，对实时性没有要求，可以运行单机单jvm进程，采用大堆。 注意新生代与年老代的比例，伊甸区与幸存区的比例，这两个比例。 如果使用了jdk7，可以尝试下G1算法，它是目前最快的gc算法。 注意，不论是重视实时性还是重视数据吞吐量，所有jvm进程堆内存最好不要超过物理内存的3/4，根据操作系统内运行的服务数量和其它进程占用的内存这一数字还需要调整。如果服务器只运行同样的java服务，3/4是个不错的参考数字。 如果是作为服务器可在启动jvm时增加-server参数，这个参数针对服务器有些默认优化，可在此基础上基于测试结果和线上运行结果做针对性优化。另外，作为服务器的话，将最大堆和最小堆的值设为一样大，节省不断调整堆尺寸的cpu开销。 参数不明白的可以上网查，本人认为比较重要的几个参数是：-Xms -Xmx -Xmn MaxTenuringThreshold GCTimeRatio UseConcMarkSweepGC CMSInitiatingOccupancyFraction SoftRefLRUPolicyMSPerMB |
|
xm_king
2012-12-28
shuhucy 写道 那就是目前直接配置单机大内存并没有很多的实际应用，配置单机大内存的主要问题在什么地方了？
单机多集群，目前主要是配置32位JDK的好，还是64未JDK的好？ 单机大内存，主要问题是如果发生GC的话，那就会消耗非常大的时间 |
 |
buzhucele
2012-12-28
xm_king 写道 shuhucy 写道 1、在大内存服务器上（比如32G），JVM怎么充分利用内存了？
单机多集群？单JVM,大的堆内存？或者其他？ 2、假如采用设置大的堆内存，比如（20G以上），怎么控制FULL GC的发生时间及频率，以避免FULL GC时对应用造成停顿？ 单独任务晚上跑System.gc? 求讨论 目前通用的解决办法，还是单机多集群。 
|
 |
chong_zh
2012-12-29
不如用用The Zing™ JVM看？目前已免费：
http://www.azulsystems.com/products/zing/virtual-machine 被称为C4（Continuously Concurrent Compacting Collector）垃圾回收，可支持高达512GB的堆空间，进行无停顿的垃圾回收，并且可以根据负载扩展或收缩堆空间。 没什么工业经验，纯属抛砖引玉 |
|
shuhucy
2012-12-31
xm_king 写道 shuhucy 写道 那就是目前直接配置单机大内存并没有很多的实际应用，配置单机大内存的主要问题在什么地方了？
单机多集群，目前主要是配置32位JDK的好，还是64未JDK的好？ 单机大内存，主要问题是如果发生GC的话，那就会消耗非常大的时间 而且转储文件应该也是没法分析的 所以实际上使用大内存问题在于需要保证程序的稳定性，逻辑上没有问题，整个应用系统应该也没有问题（有些系统采用ZK,MQ的，如果一些重试机制没处理好，易产生内存溢出） 如果使用大内存而出现内存溢出，定位应该很困难了 目前正在处理的一个实际系统，配置20G内存，性能压力测试期间，跑了几天的稳定性测试，通过VisualVM查看垃圾回收情况，发现old区基本正常，保持一个较低使用水平，没有发生过一次full gc。不过依然建议线上64位服务器上，采用单机多集群方式，但堆内存建议在4-6G区间 采用大内存时，垃圾回收采用迸发收集器，个人觉得年龄阀值可以配置大写，比如8，默认是4，因为在压力测试区间，发现年龄阀值为4时，old区增长还是较快的 |
