【问题标题】:Tomcat memory issueTomcat内存问题
【发布时间】:2011-06-05 12:10:27
【问题描述】:

我注意到我在 Tomcat 5 上运行的应用程序以 1gig 的内存开始,一旦它开始接收来自客户端的请求,内存就会开始下降,直到它下降到 100MB,并且从那里开始出现问题。我正在查看 JVM 部分下的 /manager/status 页面,其中列出了“可用内存”、“总内存”、“最大内存”。

这是内存泄漏的指标吗?即使没有来自客户端计算机的请求,内存似乎也不会自动释放。

【问题讨论】:

  • 你是什么意思,“内存开始下降”?
  • 你用什么与mem相关的选项来启动tomcat?
  • “麻烦开始”到底是什么意思?你在观察什么?
  • @antispam:通过“麻烦”,我的意思是 tomcat 需要很长时间来提供数据。我认为这与线程等待直到其他线程释放一些资源(包括内存)的内存有关
  • 这可能是由于 GC 活动阻塞了 JVM 的其余部分。如果您需要分析方面的帮助,请阅读我的回答并发布一些 GC 数据。

标签: memory tomcat garbage-collection jvm


【解决方案1】:

启用JMX on your tomcat 并使用一些分析器对其进行监控。像 Jconsole 或 visualvm。如果趋势表明堆使用量随时间快速增加,则可能存在内存泄漏。检查加载的类,您可能会找出导致此问题的原因。

另外,你的问题还不够清楚。 “内存下降”到底是什么意思?你的意思是空闲内存减少了?

【讨论】:

    【解决方案2】:

    您是否在静态块中做某事而不使用对象? 如果你只是启动服务器让它运行一段时间然后启动浏览器会发生什么?如果有未使用的对象并且 GC 已经运行,那么可用内存应该会增加。这可能无法解决您的问题,但您可以缩小范围。

    【讨论】:

    • 我在应用程序中没有任何静态块,我的理解是一旦对象超出范围,它们应该被垃圾收集并且最终应该释放内存。但这不是我注意到的。即使在最后一次活动后一个多小时,内存也永远不会被释放
    【解决方案3】:

    首先您应该analyze your garbage collection activity 并了解 GC 行为(锯齿模式)。这是explanation of GC statements

    如果您遇到不希望的长时间 GC 暂停,您应该尝试GC tuning

    如果您遇到 OutOfMemory 错误,那么您应该转到 detect memory leak

    【讨论】:

      【解决方案4】:

      与其检查代码以寻找标准泄漏模式,最好的办法是打开 GC 日志记录,然后针对这些日志运行 HP Jmeter 之类的工具。

      您可以在此处找到有关如何使用 JMeter 的说明:http://www.javaperformancetuning.com/tools/hpjmeter/index.shtml#howto

      分析 GC 日志时要寻找的一个常见模式是存在于多代中的对象。在一个普通的(非泄漏的)java 程序中,你会发现对象要么是短命的,要么是长命的,这意味着它们被快速创建和销毁,或者它们在应用程序的持续时间内存在。如果一个对象是短暂的,它只会存在一小部分稳定的世代。如果一个对象的寿命很长,它的年龄会随着程序的运行而增加。但它只属于有限的几代人。如果您发现一个对象具有多个不同年龄且代数不断增加的实例,则该对象很可能被泄露。如需更好的解释,请查看此演示文稿:http://www.hjug.org/present/Sporar-MemoryLeaks.pdf

      一旦您确定了泄漏对象,下一步就是分析堆以查看谁持有泄漏对象的引用。从那里应该很容易识别问题

      【讨论】:

        猜你喜欢
        • 2015-11-03
        • 1970-01-01
        • 1970-01-01
        • 2017-02-15
        • 1970-01-01
        • 1970-01-01
        • 2018-12-17
        • 2012-10-15
        • 2011-03-21
        相关资源
        最近更新 更多