On 4/14/2013 11:10 PM, Howard W. Smith, Jr. wrote:
On Sun, Apr 14, 2013 at 10:52 PM, Mark Thomas<ma...@apache.org> wrote:
On 14/04/2013 21:53, Howard W. Smith, Jr. wrote:
On Sun, Apr 14, 2013 at 6:51 PM, Christopher Schultz<
ch...@christopherschultz.net> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Howard,
On 4/11/13 10:38 PM, Howard W. Smith, Jr. wrote:
On Thu, Apr 4, 2013 at 2:32 PM, Christopher Schultz<
ch...@christopherschultz.net> wrote:
Your heap settings should be tailored to your environment and
usage scenarios.
Interesting. I suppose 'your environment' means memory available,
operating system, hardware. Usage scenarios? hmmm... please clarify
with a brief example, thanks. :)
Here's an example: Let's say that your webapp doesn't use HttpSessions
and does no caching. You need to be able to handle 100 simultaneous
connections that do small fetches/inserts from/into a relational
database. Your pages are fairly simple and don't have any kind of
heavyweight app framework taking-up a whole bunch of memory to do
simple things.
Thanks Chris for the example. This is definitely not my app. I am
definitely relying on user HttpSessions, and I do JPA-level caching
(statement cache and query results cache). pages are PrimeFaces and
primefaces = xhtml, html, jquery, and MyFaces/OpenWebBeans to help with
speed/performance. And right now, the app handles on a 'few' simultaneous
connections/users that do small and large fetches/inserts from/into
relational database. :)
Hopefully one day, my app will be support 100+ simultaneous
connections/users.
For this situation, you can probably get away with a 64MiB heap. If
your webapp uses more than 64MiB, there is probably some kind of
problem. If you only need a 64MiB heap, then you can probably run on
fairly modest hardware: there's no need to lease that 128GiB server
your vendor is trying to talk you into.
Understood, thanks. I have Xms/Xmx = 1024m, and I rarely see used memory
get over 400 or 500m. the production server has 32GB RAM.
I'll summarize a number of JavaOne sesisons I've been to on GC and
performance (caveat - this was a couple of years ago and GC design has
moved on since then).
- GC pause time
- throughput
- small memory footprint
You can optimise for any two of the above at the expense of the third.
Assuming you opt for min GC pause time and max throughput the question
then becomes how much heap do you need? If you look at your steady state
heap usage graph (it should be a saw-tooth) then take the heap usage at the
bottom of the saw-tooth and multiply it by 5 - that is the heap size you
should use for the GC to work optimally.
HTH,
Mark
Interesting, that does help, Mark, thanks. 250 x 5 = 1,250. I guess I was
pretty close on target when I set Xms/Xmx = 1024m.
Prior to seeing your email/response, I checked the server again, and it was
no saw-tooth at all, it was at 250 (bottom), and then saw-tooth graph came
into play...minutes later.
Make sure you give it enough time for the memory use to stabilize.
Depending on your app and usage patterns, it can take up to days for the
sawtooth to stabilize and start showing. One of mine takes a couple of
hours, and another a few days for that pattern to become visible.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
