Tomcat会话驱逐以避免OutOfMemoryError [英] Tomcat Session Eviction to Avoid OutOfMemoryError

问题描述

我们在Tomcat 5.5中运行供应商提供的webapp，使用StandardManager进行会话（在内存中）。由于会话可能会变得非常大（20M +），因此堆空间不足是一个严重问题。如果可能的话，用户希望将会话保持几个小时，但宁愿逐出会话而不是耗尽堆空间。供应商似乎没有在会话对象中正确实现Serializable，因此不能选择切换到持久会话管理器实现。

We are running a vendor-supplied webapp in Tomcat 5.5 using the StandardManager for sessions (in memory). As sessions can get quite large (20M+), running out of heap space is a serious concern. Users want to keep sessions around for a couple of hours if possible but would rather evict sessions than run out of heap space. It does not appear that the vendor properly implemented Serializable in session'ed objects, so switching to the persistent session manager implementation isn't an option.

Tomcat允许设置一个maxActiveSessions属性，它将限制管理器中的总会话数。但是，当达到该限制时，在某些现有会话到期之前，不会创建新会话。我们想首先破坏最近最少使用的会话。

Tomcat allows one to set a maxActiveSessions property that will restrict the overall number of sessions in the manager. However, when that limit is reached, no new sessions may be created until some existing sessions expire. We want to clobber the least recently used sessions first.

理想情况下，当堆使用率接近Xmx设置时，我们希望使一些最近使用的会话失效，即使它们不够老，无条件到期。一个非常古老的Tomcat开发人员邮件列表线程表明这可能允许拒绝服务攻击*，但是，由于此应用程序仅在公司网络中可用，我们并不关心。

Ideally, we would like to expire some not recently used sessions when heap usage approaches the "Xmx" setting even if they are not old enough to expire unconditionally. A very old Tomcat developer mailing list thread suggested that this might allow a denial of service attack*, but, as this application is only available within the corporate network, we are unconcerned.

如果堆使用率大于，例如，最大值的85％，我考虑扩展StandardManager以覆盖processExpires（）和clobber附加会话。然而，这在实践中似乎有点问题。如果堆没有被引用，并且垃圾收集器能够收集大量的对象（如果它不能运行）以将堆减少到最大值的50％，该怎么办？我会不必要地过期。我想我们可以通过一些积极的垃圾收集设置来缓解这种风险。另外，我怎么知道会话到期后我节省了多少内存？我必须等待几个GC周期才能确定。也许我可以采取保守的方法，每个后台进程周期最多删除N个会话，直到内存低于可接受的阈值。我可以将会话序列化作为一种​​估算GC的内容的方法，但这依赖于供应商实现Serializable并将实例变量标记为瞬态。

I thought about extending StandardManager to override processExpires() and clobber additional sessions if heap usage is greater than, say, 85% of max. However, this seems a bit problematic in practice. What if muuch of the heap is unreferenced, and the garbage collector would be able to collect a ton of objects (if it bothered to run) to reduce heap to 50% of max? I'd be expiring sessions unnecessarily. I guess we could mitigate this risk with some aggressive garbage collection settings. Also, how would I know how much memory I had saved by expiring a session? I would have to wait for a few GC cycles to know for sure. Perhaps I could take a conservative approach and remove at most N sessions per background process cycle until memory drops below an acceptable threshold. I could serialize the session as a way to estimate how much stuff would be GC'ed, but that relies on the vendor implementing Serializable and marking instance variables as transient appropriately.

有人解决了这个问题吗？作为一个短期修复，我们正在增加堆大小，但是创可贴也有其缺点。

Has anyone solved this problem? As a short-term fix, we are increasing heap size, but that band-aid has its drawbacks as well.

• 他们指的是登录前将创建会话的公共站点。有人可能会创建许多新会话并挤出实际使用的会话。

更新：我们实际上对系统架构没有太多控制权，我们特别不能减少会话使用。但是，我们可以根据自己的需要配备容器。然而，Tomcat是供应商支持的唯一开源servlet容器。

Update: We really don't have much control over the system's architecture, and we specifically can't reduce session use. However, we can futz with the container as much as we'd like. Tomcat is the only open source servlet container that's vendor-supported, however.

推荐答案

您的选择似乎是：

1. 减少空闲会话超时，


2. 使会话持久（可能仅在用户登录后），


3. 减少每个会话对象使用的内存，


4. 增加Tomcat实例的内存，


5. 运行多个服务实例，并在其前面放置一个负载均衡器。

1. reduce the idle session timeout,
2. make sessions persistent (maybe only after the user has logged in),
3. reduce the memory used by each session object,
4. increase the memory for your Tomcat instance,
5. run multiple instances of your service, and put a load balancer in front of it/them.

从技术角度来看3是最佳解决方案......如果有效的话其他人都有一个缺点。

From a technical standpoint 3 is the best solution ... if it works. The others all have a down-side.

用记忆做一些聪明的东西只是一个创可贴。从用户的角度来看，它会使您的网站行为更难理解。此外，如果您的用户群/流量呈上升趋势，那么您只能解决寻找可持续解决方案的问题。

Doing clever things with memory is only a band-aid. From the users' perspective, it makes your site's behaviour harder to understand. Besides, if your user base / traffic is trending upwards, you are only putting off the problem of finding a sustainable solution.

这篇关于Tomcat会话驱逐以避免OutOfMemoryError的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！