|
锁定老帖子 主题：JVM的GC-生命不能承受之重
精华帖 (17) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (9)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-11-18
jvm 的运行机制是一个？
|
| 返回顶楼 | |
|
发表时间：2008-11-18
最后修改：2008-11-18
建议还是查查代码吧。用JProfiler看看method的calltree。我现在在做一个系统的调优，刚开始也是怀疑服务器硬件啊，jdk版本或者heap堆内存不是最优，最后发现还是代码中的问题。有时候看来很简单的，到了系统中就是瓶颈了。举例来说吧，一个对象是使用new还是clone来创建？如果只有一个实例这个问题就不是问题，但是如果你一次运算需要2000或者20000个对象呢？在代码自身问题查明前，不要用什么cache、集群，这些方法会掩盖你系统中问题的实质。另外，数据缓存要慎重，我不敢说绝对，但是尽量不要往jvm里面放。
|
| 返回顶楼 | |
|
发表时间：2008-11-18
S0 S1 E O P YGC YGCT FGC FGCT GCT
23.39 0.00 69.88 65.27 77.91 684 200.083 16 113.838 313.921 |
| 返回顶楼 | |
|
发表时间：2008-11-18
helloboy9527 写道 我们有一个要求非常高性能的应用，其实也是部署在一台普通的PE2850上面。4CPU，内存8G，JVM的heap开了5G，其中新生代为1.5G。在高峰期每秒超过5000次调用，约3秒就需要minor GC一次，每次停顿约0.3秒。隔十分钟左右就要Full GC一次，需要停顿约10秒。有点受不了。这样相当于每隔3秒应用就要停顿0.3秒，每隔10分钟就要停顿10秒。也改成CMS试过，Full GC的停顿会减少，但minor GC照样。这样的效果，对于一些高性能的应用来算，GC可能真是无法承受之重，而如果用C++来开发，这个停顿的问题将会消除，不过当然开发成本会大很多。有个疑问，不知道GC算法何时可以做到完全不停顿，其实已经有4个CPU了，能否用一个CPU不断地在GC，另外三个CPU不断地在服务，一刻也不停顿。否则这样下去，这种高性能的应用可能只能转用C++来开发了。
如果3s就要发生一次0.3s的minor GC,是否可以调小新生代的大小为1G以内,使得1.0到1.5s时执行一次minor GC,如果这个minor GC所花时间在30ms以内就值得了(同样3s时间内,这样改了后只中断了0.09S),这样还加大了年老代大小,减少了Full GC. |
| 返回顶楼 | |
|
发表时间：2008-11-18
都是高手啊，学习中!不知道上面一直说的老生代，新生代什么意思，也希望大侠给指导下。
看了以上那么多的方案，感觉IBM的jvm可以处理并行gc问题，不知道说的对不对。 |
| 返回顶楼 | |
|
发表时间：2008-11-18
程序里面是否自己添加上了System.gc()这个语句？不要显式调用这个。
|
| 返回顶楼 | |
|
发表时间：2008-11-19
sun得jdk实现不是那种停止-复制,还有个标记-清扫
这个过程要停止程序 如果你得代码占用很大 那么这个停止过程可能会很长 1.试试别的jdk 2.修改代码 |
| 返回顶楼 | |
|
发表时间：2008-11-19
要不开个线程 隔一段system.gc一次?
|
| 返回顶楼 | |
|
发表时间：2008-11-19
检查代码质量是正解.
|
| 返回顶楼 | |
|
发表时间：2008-11-19
System.gc();不要随意调用，我还是坚持我的观点，先检查代码，用一些工具，诸如JProfiler，很多时候想当然都是错误的。
|
| 返回顶楼 | |
