On 4/15/2013 10:10 AM, Howard W. Smith, Jr. wrote:
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
These graphs are only showing ~40 seconds of data. I'll bet if you let
the app run for several minutes or hours, you'll see it.
------------------------------**------------------------------**---------
To unsubscribe, e-mail:
users-unsubscribe@tomcat.**apache.org<users-unsubscr...@tomcat.apache.org>
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
