我有一个WebSphere门户应用程序,在一个机器上运行四个实例,在运行了大约7天之后,本机内存中只有130-150mb的空闲地址空间(使用PMAP)。再过7-10天,这个数字就会降到100mb以下(我们认为这很危险,我们开始回收JVM)。如果我们不进行回收,JVM最终会崩溃并发出SIGSEGV信号。
我们已经对类计数和JIT代码的大小做了一些初步的调查。类数量不断增加,但从50k onwards...about到每天几百个缓慢增长。JITC的大小在7天后达到约210MB,此后每天增长约1MB。在我们之前的经验中,我们没有发现这些是险恶的价值观。
我们需要能够分解本机堆中的内容,无论是线程(所有线程计数都正常,我们有固定的线程池)、字符串池、常量池、字节码或其他任何东西。
我们现在正在尝试的一个线索是将反射阈值降低到0(关闭反射创建的类的字节码访问器)。这个应用程序使用了大量的切入点和反射,所以我们希望这有很好的帮助。
欢迎任何建议。
发布于 2010-10-26 21:57:27
经过长时间的调查,最终发现这是一个WebSphere错误:PK72252: CALLS TO CLASSLOADER.GETRESOURCEASSTREAM ARE SLOW。已在6.0.2.33中修复。
发布于 2010-09-23 07:38:28
可能有点来回,但是您是否记录了GC并确保它不会随着时间的推移而增加Java堆?看了你的烫发空间?不过,SIGSEGV是一个有趣的问题,对于Java中的mem问题,我预计会出现更多类似JVM的崩溃。
https://stackoverflow.com/questions/3755087
复制相似问题