分解 SLES 上 JVM 进程内的本机内存使用情况
我有一个在单个机器上运行四个实例的 WebSphere Portal 应用程序，运行大约 7 天后，本机内存中只剩下 130-150mb 的可用地址空间（使用 PMAP）。再过 7-10 天，这个数字就会下降到远低于 100mb（我们认为这是危险的，我们开始回收 JVM）。如果我们不进行回收，JVM 最终将因 SIGSEGV 信号而崩溃。
我们已经对类计数和 JIT 代码的大小进行了一些初步调查。班级数量在增加，但从 5 万起缓慢增长……每天大约几百个。 7 天后 JITC 大小达到约 210 MB，此后每天增加约 1 MB。根据我们之前的经验，我们并不认为这些是险恶的价值观。
我们需要什么才能分解本机堆中的内容，无论是线程（所有线程计数都显示正常，并且我们有固定的线程池）、字符串池、常量池、字节码还是其他任何东西。
我们现在尝试的一项措施是将反射阈值降低到 0（关闭反射创建的类的字节码访问器）。这个应用程序使用了大量的切入点和大量的反射，所以我们希望这很有可能对您有所帮助。
欢迎任何建议。
I have a WebSphere Portal application running four instances on a single box and after about 7 days of runtime there is only 130-150mb of address space free in native memory (using PMAP). Somewhere in another 7-10 days the figure drops well below 100mb (which we deem dangerous and we start to recycle the JVM). If we don't do the recycle, the JVM will eventually crash with a SIGSEGV signal.
We've done some initial investigation into class counts and the size of JIT code. Class counts grow, but slowly from 50k onwards...about a couple hundred per day. JITC sizes get to about 210 MB after 7 days and grow about 1 MB per day after that so. In our previous experience we don't find these to be sinister values.
What we need to to be able to break down what is in the native heap, whether it is threads (all thread counts appear normal and we have fixed thread pools), String pools, constant pools, bytecode, or whatever else.
One lead we are trying now is reducing the reflection threshold to 0 (shutting off the bytecode accessors for reflectively created classes). This app uses a lot of pointcutting and a lot of reflection, so we're hoping there's a good chance this helps.
Any advice is welcome.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
可能有点反复，但是您是否记录了 GC 并确保 Java 堆不会随着时间的推移而增长？看看你的烫发空间了吗？不过，SIGSEGV 是一个有趣的问题，我预计任何 Java 内存问题都会出现更多 JVM 崩溃。
Might be a bit of back-and-forth, but have you GC logged and ensured it's not growing Java heap over time? Looked at your perm space? The SIGSEGV is an interesting one though, I'd expect a more JVM-ish crash for any in-Java mem issues.
经过长时间的调查，这最终成为一个 WebSphere bug：PK72252 ：对 CLASSLOADER.GETRESOURCEASSTREAM 的调用很慢。已在 6.0.2.33 中修复。
After lengthy investigation, this ended up being a WebSphere bug: PK72252: CALLS TO CLASSLOADER.GETRESOURCEASSTREAM ARE SLOW. Fixed in 6.0.2.33.