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. Thanks again! > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@tomcat.**apache.org<users-unsubscr...@tomcat.apache.org> > For additional commands, e-mail: users-h...@tomcat.apache.org > >
