普通 jsp 站点上可能存在内存泄漏

发布于 2024-08-02 23:45:04 字数 401 浏览 3 评论 0原文

首先,我撒谎,这并不是一个真正的普通jsp网站。它有几个带有数据库访问的页面和一个基于 lucene 的搜索引擎...以及大约 400 个独立的 jsp 页面。

问题是我们无法访问的生产服务器上的管理员说该站点消耗了太多内存(200+ Megs),并且我们可能面临内存泄漏,因为这迫使他们重新启动它。

我不是jsp专家,但我怀疑这并不是真正的内存泄漏,数据库页面和lucene搜索与这个问题无关。我的理解是每个jsp页面都会编译成一个java类,然后执行,并保存在内存中以供以后访问。

真正的问题是:独立 jsp 页面数量的增加(400 个,我认为是的)是否会导致内存使用量增加到 200M?

如果是,您将如何降低内存使用量?使用 SSI 进行包含(避免为此目的使用 jsp 页面)可能是一种选择?

提前致谢

First of all, I lie, it's not really a plain jsp website. It has a couple of pages with database access and a lucene based search engine... and around 400 standalone jsp pages.

The problem is that the admins on a production server we've not access to, say that the site is consuming too much memory (200+ Megs), and we are probably facing a memory leak, because it forces them to reboot it.

I'm not a jsp expert, but I suspect that it's not really a memory leak, and that the database pages and the lucene search have nothing to do with this issue. I understand that each jsp page is compiled to a java class, then executed, and kept in memory for later access.

The real question is: Can this elevated (for 400, i think yes) number of standalone jsp pages cause the memory usage to grow up to 200M?

And if yes, how would you lower the memory usage? Using SSIs for includes (avoiding the use of jsp pages for that purpose) could be an option?

Thanks in advance

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

智商已欠费 2024-08-09 23:45:04

每个 JSP 半兆字节并不是我通常所期望的。显然,人们可以在 JSP 中编写任何喜欢的代码,因此编译后的 JSP 可能会很大并且可以分配大量内存,但假设这些是传统的 JSP,那么我最怀疑的是运行时行为而不是剪切JSP 的数量。

一种可能性是您有大量会话数据。当用户从一个页面移动到另一个页面时,会话大小可能会增加。从数据库检索的数据临时放置在会话中以便可以在另一个页面中使用是很常见的。如果不加以整理,您可能会迅速消耗大量内存。

Half a megabyte per JSP is not what I'd usually expect. Obviously, one can write any code one likes in a JSP so a compiled jsp can be huge and can allocate huge amounts of memory, but assuming that these are conventional JSPs then I'd me most suspicious of run-time behaviours rather than the shear number of JSPs.

One possibility is that you have a lot of session data. As users move from page to page the session size might be increasing. It's quite common to see data retrieved from a database temporarily place in a session so that it can be used in another page. If that doesn't get tidied up you can rapidly consume lots of memory.

电影里的梦 2024-08-09 23:45:04

了解什么消耗了内存的唯一方法是使用分析器。我们所做的是获取堆转储,然后按以下方式对其进行分析:

  • 使用 jmap 实用程序(JDK 附带)来获取堆转储。它应该以 root 身份运行!
  • 将文件下载到本地计算机
  • 下载并安装 Eclipse Memory Analyser - 还有其他的(例如 < a href="http://java.sun.com/javase/6/docs/technotes/tools/share/jhat.html" rel="nofollow noreferrer">jhat),但我个人喜欢它。
  • 用它打开文件
  • 查看哪些类占用了大部分内存。

无论如何,在服务器启动之前预编译 JSP 总是好的。

The only way to know what consumes the memory is to use a profiler. What we do is to take a heap dump and then analyse it, in the following manner:

  • Use the jmap utility (comes with the JDK) to get the heap dump. It should be run as root!
  • Download the file to a locale machine
  • Download and install the Eclipse Memory Analyser - There are others (like jhat) but I personally like it.
  • Open the file with it
  • See which classes takes most of the memory.

Regardless, it is always good to pre-compile the JSPs before the server boots.

紧拥背影 2024-08-09 23:45:04

您需要确定内存消耗在哪里。 200MB 太多的说法实际上是没有用的,因为它取决于使用情况、应用程序如何使用内存(例如 David 提到的会话数据)。您需要分析应用程序生命周期中不同时间的堆转储和详细 gc 日志,以了解使用情况以及是否确实存在内存泄漏(如果应用程序稳定在 200MB,则不会。如果它每 x 小时增加一次)没有减少的迹象,你可能会这样做)。

You need to determine where that memory is spent. The statement that 200MB is too much is really useless, as it depends on the usage, how the application is using memory (e.g. session data as David mentioned). You need to analyse heap dumps and verbose gc logs from various times in the application's lifecycle to understand the usage and whether you do in fact have a memory leak (if the application is stable at 200MB you don't. If it increases every x hours with no sign of decreeasing, you probably do).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文