如何分析 Java/Seam Web 应用程序中的会话内存使用情况？
有没有什么方法/工具可以分析 Java Web 应用程序中每个会话的内存使用情况？
更具体地说，我正在使用 Seam，并且有一些特定于用户或用户当前会话的对象，因此它们被设置为存储在用户的会话中。
不久前，我的应用程序在达到一定数量的用户时会耗尽内存，因此我将各种内容从会话中移出并进行分析，直到内存耗尽为止。 然而，内存测量是在 JVM 级别进行的。 我真的很想要一种方法来监视会话级别的内存使用情况，排除任何非会话内存使用情况。
很高兴拥有：
- http 会话的总内存使用量（我可以将其与整个应用程序的内存使用量进行比较）
- 每个会话的内存使用量，甚至是平均值。
Is there any way/tool to profile per-session memory usage in a Java web application?
More specifically I'm using Seam and I have a few objects which are specific for the user or for the user's current session so they're set to be stored in the user's session.
Some time ago my application would run out of memory when hitting a certain number of users so I moved various things out of the session and profiled until I got the memory down. However the memory measurements were at the JVM level. I'd really like a way to monitor memory usage on session level, excluding any non-session memory usage.
Nice to have:
- Total memory usage for http sessions (which I can compare to whole application memory usage)
- Per-session memory usage, even averages.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
看看 http://messadmin.sourceforge.net/ 。
Have a look at http://messadmin.sourceforge.net/ .
我经常使用 Eclipse Mat 来诊断类似的问题。 如果您有大型会话，会话管理器会显示在“Dominator Tree”报告中。 您可以轻松区分会话和应用程序其他部分的总内存使用情况。
您可以深入查看各个会话并查看每个会话使用了多少内存。 您还可以打开每个单独的会话并检查会话中的每个对象。
查看 MAT 提供的其他报告也是一个好主意。 有时结果令人惊讶 - 例如，我们遇到了内存使用问题，结果是 JRE 类加载器问题。
I use Eclipse Mat a lot to diagnose similar issues. If you have big sessions the Session Manager shows up in the "Dominator Tree" report. You can easily distinguish total memory usage by sessions and other parts of the app.
You can drill down to individual sessions and see how much memory is used by each. You can also open each individual session and inspect each object in the session.
It is also a good idea to look at the other reports that MAT provides. Sometimes the results are surprising - for example we had an issue with memory usage that turned out to be a JRE classloader problem.