-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark,
On 12/1/11 9:50 AM, Mark H. Wood wrote: > On Thu, Dec 01, 2011 at 12:38:01PM +0100, Mikolaj Rydzewski wrote: >> On the other hand, increasing java heap size is not always the >> best option. It heavily depends on memory usage pattern in your >> application. In general: the bigger heap, the longer GC will >> run. > > I was thinking that someone should bring this up. When a program > uses unexpectedly huge amounts of memory in practice, the *first* > thing to consider is: > > 1. does it actually need that much? +1 !! > 2. ...or is it leaking dynamically created objects? 3. ...or has > cheap allocation and garbage collection lured me into doing > something suboptimal, like sucking down an entire database table > into an array or list and then walking it sequentially, when I > could have used an iterator and let the DBMS code work out > near-optimal buffering? > > IOW "is my problem fundamentally this big, or is something else > going on?" The 2 times our production servers have suffered OOMEs, it's been because we were running with fairly small, (intentionally) restricted heaps (64MiB at first, then 192MiB) and our traffic simply increased beyond our heap size: we had a legitimate reason to increase the heap size (and plenty of physical RAM available to do it). - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7YLEwACgkQ9CaO5/Lv0PCGTQCfSwBVBLSKIW2OMjYZWVobxrKY JzkAoJQmi4JK2CHqo23DCuMRGE5Fzq/0 =Qte1 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
