iteye_15376
iteye_15376
2008-12-17 16:31
浏览 477
已采纳

怎么能观察出JVM的Old区中存储的都是那些对象

操作系统:Solaris10
JDK:SUN JDK1.5.0_17

[b]问题补充:[/b]
jmap这个命令我用了,但我发现只是显示出了实例的数量。看不出来哪些对象是在Old区的。你说用Heap工具分析,是什么Heap工具呢?我用了Optimizeit,也是只能看出实例的数量和引用关系,看不出哪些对象是在Old区的。
[b]问题补充:[/b]
我现在的GC策略是这样的,堆最大,最小都是1024m,young区是512m,对象在from和to之间拷贝5次然后扔到old区。回收算法用的是cms。我们的应用对吞吐量的要求比较高,绝大多数都是短生命周期的对象。我在windows下用optimizeit检查了,不存在内存泄漏,但发现在并发量比较大的时候,有几个对象的实例数量是一直在增长的。但当客户端的程序停止的时候,这些对象又是可以被回收的。我们的程序是运行在solaris上的,由于我没下载到optimizeit的solaris安装文件,或者是类似工具的solaris安装文件,因此不确定,olc区中的那些对象是否就是那几个不断增长的对象。我用jvmstat看了,old区涨的很快。而且程序运行大概20分钟左右就core dump了。有的时候会直接把服务器整死。因此我想看看有没有什么手段来看看old区的对象存储的都是什么来帮我肯定一下,就是那几个对象再搞鬼。
[b]问题补充:[/b]
其实这个问题,在昨天临下班之前的10几分钟突然有了进展。终于排查出,我们的程序是没有内存泄漏的。而是由于传输层的拥挤造成的。设置了socket的readReceiveBuffer和sendBuffer之后这个问题得到了缓解。但是为什么会因为传输层的拥挤导致我们old区的对象很多,这点需要再好好研究一下mina框架。
[b]问题补充:[/b]
[quote]根据你的说法, 我觉得你的,配置有问题的, 为什么设计-Xmn512m, 这个是很关键的, 如果你要求很低的world stop. 那么把-Xmn设置到128 或者256m, core dump 的原因可能是因为你CMS机制不起作用, 导致并行收集过多产生的。 另外,也跟你的JAVA的版本有关系。 CMS最好使用JAVA6的版本, 在JAVA5上, 这个技术并不是非常成熟。如果是JAVA5, CMS的启动策略是有BUG的, 这个你可以参考我的BLOG : http://sdh5724.iteye.com/admin/blogs/283977 [/quote]

young区默认的大小是堆的1/4,但是对于吞吐量优先的程序,可以设置为堆的1/2。因为对象的生命周期短,应该尽可能的让对象在young区就被回收掉,免得被拷贝到old区,再进行回收时,暂停时间会相对较长。网上有些资料显示了,对于吞吐量优先的程序,应该设置一个较大的young区的说法,Sun的网站上也有,将堆设置为3G,young区设置为2G的例子。你说的CMS最好在JAVA6下用,这个我真的不知道。听说JAVA6的GC机制要比JAVA5好。这个我回去试试。

[quote]readReceiveBuffer和sendBuffer 是操作系统参数, 如果你的OS内存很紧张, 也可能导致系统资源不够。 这个参数应该调整成你业务需要的发送接收的大小, 不可以盲目扩大, 每个TCP连接都会占用这个BUFF的大小。 我建议你一般设置成8K。[/quote]

你说的这个我很关系,对这两个参数我也不太了解,但的确是缓解了问题,而且很明显。目前我们只使用了一个TCP连接。对于你说的“这个参数应该调整成你业务需要的发送接收的大小”,我不太明白是什么意思。主要是我不清楚我们需要的大小是多少啊,呵呵。你说的8K,这个是默认配置。但我们使用这个配置时,程序最多只能跑20分钟,程序就死掉了。这涉及到tcp的传输,因为跟我们对接的另一端,他们是C语言写的,目前他们没有设置缓冲区大小,应该用的也是默认的,但C程序我不太了解,不知道是多少。我把这个缓冲区设置为Integer的最大值了,好像是2G(我也觉得有点儿夸张),程序大概跑了四十分钟,服务器宕机了。

[quote]我觉得, 你是不是因为TCP的连接断开后, 没有释放TCP连接? socket.close(). 会导致大量的time_wait的连接, 你要仔细看下。 OS会在比较长的时间回收[/quote]

我们现在就一个TCP链接,出现问题时,链接没断过。我们应该是没有内存泄漏的,我用Optimizeit检查了好多次了。

很高兴与你讨论这个问题,我感觉现在问题出现在TCP的缓冲区上,应该让C那边也设置一个较大的缓冲区,然后再看看问题能不能得到解决。
[b]问题补充:[/b]
经过几天的测试,总结如下:
1.机器宕机居然是机器的问题,那个机器,不管上面运行的是我们的应用程序还是模拟器,都会宕机。换了其他的几台服务器,都没出现宕机的问题。
2.buffer的设置:我们一个消息的长度是20个字节。每秒钟2000条消息,就是40000个字节,因次buffer设置为40000。但最后还是没有设置这个值采用默认的。因为问题可能不在这里。
3.目前的问题,使用mina的client接收消息时,每秒钟2000条,大概运行一段时间之后,就会mina就会接收到一个很大的包(100K以上)。这导致我们应用层解析这个消息的时候调用层次过多,抛出stackOverFlow的异常,并且主动把连接关闭了。其实,我们可以修改一下我们的代码,避免抛出这个异常。但这不是问题的根源,因为mina传了一个这么大的数据包给应用层就是不正常的。于是我看了一下mina的代码,在read的时候,会根据接收到的消息的长度,来调整allocate的长度。这个上限是receiveByteBuffer的2倍。我尝试修改了mina的代码,让他每次固定allocate 1024个字节。但是问题依然存在,目前没找到解决方法。为了规避这个问题,只是让服务端不给我们发送这个应答,这在业务上是允许的。但没找到问题的根源总是感觉心里堵的荒,打算试试grizzly。

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 邀请回答

6条回答 默认 最新

  • u011537602
    不良校长 2008-12-20 23:44
    已采纳

    你说的这个我很关系,对这两个参数我也不太了解,但的确是缓解了问题,而且很明显。目前我们只使用了一个TCP连接。对于你说的“这个参数应该调整成你业务需要的发送接收的大小”,我不太明白是什么意思。主要是我不清楚我们需要的大小是多少啊,呵呵。你说的8K,这个是默认配置。但我们使用这个配置时,程序最多只能跑20分钟,程序就死掉了。这涉及到tcp的传输,因为跟我们对接的另一端,他们是C语言写的,目前他们没有设置缓冲区大小,应该用的也是默认的,但C程序我不太了解,不知道是多少。我把这个缓冲区设置为Integer的最大值了,好像是2G(我也觉得有点儿夸张),程序大概跑了四十分钟,服务器宕机了。

    程序死了, 我不知道是你的服务端死了 还是客户死了。
    另外, 你的JAVA程序, 怎么能把缓冲设置成最大? 你根本不明白这参数的含义。 输入输出的缓冲区, 如果不是性能高度要求, 不需要调整的。 你根本不应该设置这么的BUFF, 当然会导致你的JAVA程序死掉。

    输入输出的缓冲区,一般是根据你的一次发送/接收多少数据决定的, 一般情况下, 默认值是足够使用的。 如果你真的需要提高一次就发送32K的数据的网络性能, 你可以把发送区设置成32K大小。 一般来说, 你没有必要修改这个东西。

    另外,我有点东西需要提醒你的是, 如果你把JAVA IO/NIO混合使用的话, 会导致严重的JAVA程序刮起。 千万不可混合使用这些API。

    程序死了的时候, 是CORE DUMP还是挂起了, 这个需要明白, 如果是CORE DUMP你需要看看CORE DUMP的文件, 如果是挂起了, 你需要看看JAVA程序的当前执行栈的情况。 使用kill -3 把执行线程DUMP出来。

    点赞 评论
  • u011537602
    不良校长 2008-12-18 22:27

    JMAP 命令! 然后用HEAP分析工具!

    点赞 评论
  • u011537602
    不良校长 2008-12-19 18:32

    首先, 长时间持有的对象肯定是在OLD区域。 另外, 在DUMP的参数上, 可以把非live对象删除。 另外, OLD区域的定义, 他不是固定不变的。 看你的内存收集类型, 如果是并行和传统的方式, 那么有OLD区域的, CMS收集机制, OLD的概念很模糊的, 他实际上就可以看成2个区域, 一个是新生代, 一个长时间持有对象的区域。 因此, 你一定要把OLD区域DUMP出来想法是不对的。 另外, 你如果想仅仅是看占用大小, 我建议你使用jstat -gcutil pid 1000 1000 。
    看OLD区域的有哪些对象的意义不是很大吧。 不是很清楚, 你的目的是什么。 很多事情也可以变通想的么。

    点赞 评论
  • u011537602
    不良校长 2008-12-20 17:32

    我现在的GC策略是这样的,堆最大,最小都是1024m,young区是512m,对象在from和to之间拷贝5次然后扔到old区。回收算法用的是 cms。我们的应用对吞吐量的要求比较高,绝大多数都是短生命周期的对象。我在windows下用optimizeit检查了,不存在内存泄漏,但发现在并发量比较大的时候,有几个对象的实例数量是一直在增长的。但当客户端的程序停止的时候,这些对象又是可以被回收的。我们的程序是运行在solaris上的,由于我没下载到optimizeit的solaris安装文件,或者是类似工具的solaris安装文件,因此不确定,olc区中的那些对象是否就是那几个不断增长的对象。我用jvmstat看了,old区涨的很快。而且程序运行大概20分钟左右就core dump了。有的时候会直接把服务器整死。因此我想看看有没有什么手段来看看old区的对象存储的都是什么来帮我肯定一下,就是那几个对象再搞鬼。

    根据你的说法, 我觉得你的,配置有问题的, 为什么设计-Xmn512m, 这个是很关键的, 如果你要求很低的world stop. 那么把-Xmn设置到128 或者256m, core dump 的原因可能是因为你CMS机制不起作用, 导致并行收集过多产生的。 另外, 也跟你的JAVA的版本有关系。 CMS最好使用JAVA6的版本, 在JAVA5上, 这个技术并不是非常成熟。如果是JAVA5, CMS的启动策略是有BUG的, 这个你可以参考我的BLOG : http://sdh5724.iteye.com/admin/blogs/283977

    点赞 评论
  • u011537602
    不良校长 2008-12-20 17:34

    readReceiveBuffer和sendBuffer 是操作系统参数, 如果你的OS内存很紧张, 也可能导致系统资源不够。 这个参数应该调整成你业务需要的发送接收的大小, 不可以盲目扩大, 每个TCP连接都会占用这个BUFF的大小。 我建议你一般设置成8K。

    点赞 评论
  • u011537602
    不良校长 2008-12-20 17:41

    我觉得, 你是不是因为TCP的连接断开后, 没有释放TCP连接? socket.close(). 会导致大量的time_wait的连接, 你要仔细看下。 OS会在比较长的时间回收。

    点赞 评论

相关推荐