这是一个创建于 3380 天前的主题，其中的信息可能已经有所发展或是发生改变。
ps: 硬件环境 aliyun ECS ， 2 core ， 4g
第 1 条附言 · 2015-08-21 20:32:27 +08:00
再来一张现在的截图
 |
1
CheungKe OP 再来一张现在的截图
 |
 |
2
stevegy 2015-08-21 20:49:12 +08:00
这么频繁的 GC ？ 10 分钟 1 次？ 1G 的 heap 可能太少。。。不过照这个趋势， 2G 也撑不过 20 分钟。。
第二套监控的 memory 貌似一直在 1G ，有大量线程运行时间超长。。。这个可以在 visualVM 里看到是哪些线程运行这么长时间。。。 要么是这个系统确实很大负载。。。但先看看那些运行时间猛涨的线程吧 |
 |
3
coolcfan 2015-08-21 21:42:59 +08:00
有插件可以装，比如 VisualGC 插件能显示出分代的 GC 状况。
当然仅仅看图表是不够的；可以用这些插件来直接获取 Thread Dump 、 Heap Dump 并且在 VisualVM 的界面里浏览；还可以做 CPU Sampling/Profile 来研究一段时间内的运行情况。 |
|
4
CheungKe OP @stevegy
1. 没有接触过其他程序，不知道什么指标算正常？ 现在 jvm 设置为 -Xms2g -Xmx2g 。看起来比较正常。 2.有 10 个线程是在不停的转储图片，并带有一些校验和翻转，都是长任务。 3.现在还附加了个投票功能，每天 10w 票不到。  ) |
|
5
stevegy 2015-08-22 07:39:47 +08:00  1
第三张图的负载不高
图二是明显在 7:45 开始有比较高的负载，然后开始有大量的 GC ， jvm heap 基本用完了。照这个负载， 2G heap 还是有必要的 |
|
6
CheungKe OP 这台机器是 4g 的内存，是部署 4 个 tomcat x 1g ，还是 2 x 2g ，或者 1 x 4g ，哪个更好
|
 |
7
cloud107202 2015-08-22 10:38:06 +08:00 2
GC 频繁，堆内存设置的不够往往是表象。有一种常见的原因是系统里个别对象产生过快，而消费速度跟不上生产速度。找一找代码中哪些逻辑会快速生成大量对象，在处理时候，这些对象可以放到有界阻塞队列里限制一下总数量。
|
Select Language