tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: java.lang.OutOfMemoryError: Java heap space
Date Thu, 08 Oct 2009 01:29:09 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joe,

On 10/7/2009 8:40 PM, Joe Hansen wrote:
> WoW! "jmap" was a great command to learn Chris! Thank you so much!

Yeah, it's great as a poor-man's memory profiler. On the other hand, I
haven't seen a big-time memory profiler offer such a simple view of
everything since Borland's OptimizeIt.

> As you've pointed out, most of the data is taken by character arrays,
> Strings, integer arrays, byte arrays, Foto and FotoSet beans! There
> were just 67 Ticket entries (related to CAS) and the size of the
> Ticket objects wasn't huge either.

Yup, it looks like you have more of your application objects taking up
memory than the tickets you were worried about.

> I had changed the session-timeout in server.xml from 30 minutes to 240
> minutes. That means an HTTP Session would now last 8 times longer.
> Since the Garbage Collector runs only when the session expires, the
> application's memory needs are probably increased 8 fold (Am I
> right?).

Er, the GC runs all the time, but the objects in the session are not
cleaned-out until the session expires. You might want to consider
"cleaning" your sessions a bit more regularly. You can couple
session-object expiration with lazy instantiation/fetch for a solution
that can keep your sessions lightweight yet allow insanely long session
timeouts. It will require you to do some additional work, but improved
stability is probably worth it.

> Should I just decrease the session-timeout to 2 hours and see if 512MB
> is sufficient? Any other thoughts/ideas guys?

I think your session timeout should be dictated by your business
requirements, not technical limitations (since this is a relatively low
technical hurdle).

Is it an absolute requirement that these objects be stored in the
session at all? If so, then maybe the caching strategy can be tweaked a
bit to allow both requirements to peacefully coexist.

There are even techniques that will allow your session objects to expire
when memory gets tight (which is super cool IMO).

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrNQGUACgkQ9CaO5/Lv0PD1XwCePdhJbbdSakmn2x9uopHrN7Na
6R8AoMDfMpMioh/J2D+UfpJTUxFiHJ3G
=avdi
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message