On Mon, Apr 15, 2013 at 7:40 AM, David kerber <dcker...@verizon.net> wrote:
> 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. Will do (and doing that), thanks. :) > 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. I see it stabilize 'in minutes' (after/during usage of the app). Just now (prior to writing this email), I was looking at the app's usage (via monitoring the app's own data/record audit trail page), and then decided to check-on the app to see how it is doing/performing via jvisualvm, and voila, again, I saw no saw-tooth[1]. I saw this, 5 to 15 minutes after a period of inactivity in the app, but before I logged into the app, as I stated above, I checked the app's audit trail (which can definitely be a 'heavy-lifting' database query, depending on work done within the app on selected date, default = current date), and it[1] still showed no activity (or saw-tooth); I assume activity within the app can = definite/obvious saw-tooth graph (which also means, GC is working while app is being used). What I mentioned above is very normal behavior for my app. [1] http://img805.imageshack.us/img805/8453/20130415jvisualvm01.png > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@tomcat.**apache.org<users-unsubscr...@tomcat.apache.org> > For additional commands, e-mail: users-h...@tomcat.apache.org > >
