J2EE Struts 应用程序中的意外堆使用
我对我的应用程序中的堆使用情况有一些疑问。有时观察到周末的用户活动很少（或 nil ），但堆使用量线性增加，达到导致 GC 启动的阈值。我希望分析此堆使用量的原因并确认这是否正常且符合预期。假设没有用户活动，此堆使用可能是由守护进程（例如我的应用程序的守护进程或 Weblogic 线程）引起的。如何确认哪个守护进程导致了此行为？是否需要执行任何操作来解决此问题？
我已经对我的应用程序的守护进程进行了大量测试，并且相当有信心它没有滥用堆。 但是我可以用Weblogic的守护进程做什么呢？我应该忍受它还是与之抗争？
编辑：我正在 Weblogic 10.3 上运行 BEA JRockit 1.6。在运行垃圾收集器之前的大约 20 小时内，观察到堆使用量呈线性增加。我已经使用 JProbe 测试了我的应用程序的流程，没有发现任何泄漏。
I am having few queries regarding heap usage in my app. At instances it is observed that user activity is minimal (or nil ) on weekend but heap usage increases linearly, reaches the threshold causing the GC to kick in. I wish to analyze the cause of this heap usage and confirm if this is normal and expected. Assuming no user activity, this heap usage may be caused by daemon process such as my app's daemon process or Weblogic threads. How can I confirm which daemon process is causing this behavior and is there anything that needs to be done to resolve this ?
I have heavily tested my app's daemon process and fairly confident that its not misusing heap.
But what can I do with the Weblogic's daemon process ? Should I live with it or give it a fight ?
EDIT: I am running on Weblogic 10.3 with BEA JRockit 1.6. The linear increase in heap usage is observed for about 20 hours before the garbage collector is run. I have tested my app's process with JProbe and didn't found any leaks in that.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我肯定会尝试寻找问题（这可能是在您的代码中，而不是在 WebLogic 中）。问题是您没有提供有关您的环境（例如 WLS 版本、Java 版本、平台）或您的问题（例如 GC 之前需要多长时间）的详细信息，因此提供指导有点困难，但是......
如果这是一个选项，我会使用 VisualVM 分析此内存泄漏（或您选择的分析器）。如果可能的话，尝试在本地环境中重现问题，会更容易。如果没有，这里是 JMX URL：
只需确保启用匿名管理员查找：转到域 >安全>常规并选中启用匿名管理员查找复选框）。
另请确保为管理服务器和应用程序服务器启用 IIOP 协议：转至服务器 >协议，然后选中IIOP复选框）。还要确保
另一种选择是获取一些堆转储并使用 Eclipse MAT 等工具对其进行分析。
更新：由于 GC 之前大约需要 20 小时，我会安排一个任务来生成一些堆转储（例如每小时一次）并分析它们以找出随着时间的推移哪些对象占用了内存。这可能会提示罪魁祸首的过程。
I would definitely try to hunt the problem (which is probably in your code, not in WebLogic). The problem is that you didn't give much details about your environment (e.g. WLS version, Java version, platform) or your problem (e.g. how much time it takes till the GC) so it's a bit hard to provide guidance but...
If this is an option, I'd use VisualVM to analyze this memory leak (or the profiler of your choice). If possible, try to reproduce the problem in a local environment, it will be easier. If not, here is the JMX URL:
Just make sure to enable Anonymous Admin Lookup: go to Domain > Security > General and check the Anonymous Admin Lookup Enabled checkbox).
Also make sure to Enable IIOP Protocol for Admin Server and Application Servers: go to Server > Protocol, and check the IIOP checkbox). Also be sure that
Another option would be to take some heap dumps and to analyze them with a tool like Eclipse MAT.
Update: Since it takes around 20 hours before the GC, I would schedule a task to generate some heap dumps (e.g. one per hour) and analyze them to find out what objects eat memory over time. This might give an hint on the culprit process.
看起来像是 J2EE 服务器的正常行为。即使您的应用程序上根本没有负载，服务器上也会有一些活动（内务管理、监视等），这些活动将继续创建对象。即使您正在进行的分析堆使用情况的活动也会创建对象。
我认为对象创建的速率非常低，因为填充堆并启动 GC 周期需要 20 个小时。有关您的担忧的更多详细信息可能会有所帮助
，即
- 您是否遇到 OutOfMemory 错误
- JVM 启动参数是什么？ （堆大小、垃圾收集器类型等）
Seems like the normal behavior of a J2EE server. Even if there is no load at all on your apps there will be some activity on the server (House keeping, monitoring etc) that will keep creating objects. Even the activity of analyzing the heap usage as you are doing will create objects.
Im thinking the rate of object creation is very minimal given the fact it take 20 hours to fill the heap and kick off a GC cycle. A bit more details regarding your concern might help
i.e.
- Are you getting OutOfMemory errors
- Whats are the JVM startup args? (Heap sizes, Garbage collector type, etc..)
查看包装盒上的 prstat，了解周末运行的任何其他作业。 cron/备份作业等运行并访问您的服务器是很常见的，并且团队已经忘记了为什么要设置这些作业。
Take a look at prstat on the box for any other jobs running on the weekend. It is quite common that cron/backup jobs etc run and hit your server and the team has forotten why those were set up in the first place.