【发布时间】:2009-01-27 13:23:33
【问题描述】:
我在 JBoss 中有一个非常奇怪的行为,我想利用 SO Crowd 的集体智慧。
我们使用 JBoss(我认为是 4.0.4)来服务 SOAP 调用。事实上,它被用作美化的 RPC 服务器,仅此而已。当我们有 20 多个客户同时发送他们的请求时,我们的内存就会用完。这些请求由传入的相当小的请求(正确的 SOAP)和返回的结果包组成,该包本质上是一个长 SOAP 字符串(并且字符串的内容是 XML)。是的,我意识到这是次优的。不要问。
我已经追踪到一个 org.jboss.axis.message.SAX2EventRecorder 实例的泄漏,该实例包含 400 万个对象(字符串和整数)。现在,即使是最长的响应也不携带 4MB 的数据。请求都小于 40K。那里有些可疑,但我在网上找不到任何文档。
谁能告诉我录音机是干什么用的?我该如何摆脱它?或者可以将其配置为更少占用内存?任何帮助表示赞赏。
更新:澄清一下 - 我确实做了内存转储,转储显示了一个数组或 4,000,000 多个对象、字符串和整数。该数组由 org.jboss.axis.message.SAX2EventRecorder 拥有,而后者又由这些人持有:
org.jboss.axis.message.SOAPEnvelopeAxisImpl@0x19c31fd8(141 字节):现场记录器 org.jboss.axis.message.RPCParamElementImpl@0x19c32260(123 字节):现场记录器 org.jboss.axis.message.SOAPBodyAxisImpl@0x19c32160(121 字节):现场记录器 org.jboss.axis.message.RPCElement@0x19c321e0(124 字节):现场记录器 org.jboss.axis.encoding.DeserializationContextImpl@0x19c332f0(67 字节):现场记录器 org.jboss.axis.message.SAX2EventRecorder$objArrayVector@0x19c33398(24 字节):字段 this$0
我们自己的应用程序的数据结构非常臃肿,但还没有到这种程度。
另一个更新:powers that be 找到了“powers-that-be-solution”:我们正在切换到 64 位内存。欢呼。
【问题讨论】:
-
@Arkadiy:不要假设 JBoss 中存在错误;假设错误在您的代码中。您已经确定了软件的一种“次优”条件。为什么不能有更多?
-
我的问题是:你在运行这么旧版本的 JBoss 做什么?这是2.5岁。您经常会发现人们对使用过时的软件感到犹豫甚至不愿提供帮助。
-
@Gortok - 我确实承担了我们自己的错,但是那个该死的数组负责一半的内存使用,它与我们无关。而且,它的保存方式(请参阅更新)可能会为每个正在进行的请求分配它 - 这解释了为什么我们只有在一定数量的请求正在进行时才会失败。
-
@cletus: - “企业”环境 - 三个大洲的三个开发团队,没有人准备好承担责任。
-
我刚刚在类似的事情上运行了一个带有 bea 支持的案例。他们做任何事情所需的信息是:JRA 记录、MissionControl MemLeak 屏幕截图、垃圾收集日志和来自 jvm 的任何转储文件