Young generation configuration

[jeff.lloyd at algorithmics.com]

Hi Ramki,

I did not know that lower pause times and higher throughput were
generally incompatible.  Good to know - it makes sense too.

I'm trying to find out how long "too long" is.  Bankers can be fickle.
:-)  Honestly, I think "too long" constitutes a noticeable pause in GUI
interactions.

How did you measure the proportion of short-lived and medium-lived
objects?

We typically expect a "session" be live for most of the day, and
multiple reports of seconds or minutes in duration executed within that
session.  So yes, I am seeing my "steady state" continue for a long
time, with blips of activity throughout the day.  We cache a lot of
results, which can lead to a general upward trend, but it doesn't seem
to be our current source of object volume.

Thanks for your help,
Jeff

-----Original Message-----
From: Y.S.Ramakrishna at Sun.COM [mailto:Y.S.Ramakrishna at Sun.COM] 
Sent: Friday, September 11, 2009 2:14 PM
To: Jeff Lloyd
Cc: hotspot-gc-use at openjdk.java.net
Subject: Re: Young generation configuration

Just some very general remarks ...

>> jeff.lloyd at algorithmics.com wrote:
...
>>> My goal is to maximize throughput and minimize pauses.  I'm willing
to 
>>> sacrifice ram to increase speed.

Ah, but you may not be able to achieve a joint optimum there;
on the contrary, maximal throughput is often achieved at
maximal pause times. Lowering pause times to within budget
currently often involves giving up some throughput.
You need to define the maximum pause time you can stand and
the minimum throughput you can tolerate, and solve that
optimization problem.

...
>>> The problem is that some of the pauses are just too long.

Hmm, good, we are getting closer :-) How long is "too long"?

...
>>> Is there a way to reduce the pause time any more than I have it now?

yes, but you will likely give up on throughput.

>>>
>>> Am I heading in the right direction?  I ask because the default 
>>> settings are so different than what I have been heading towards.

Depending on your boundary conditions (constraints on your
objective metrics, and if you can define a suitable utility
or objective function) there may be multiple optimal configurations,
or none at all, which will meet your constraints.


>>> I think I have a lot of medium-lived objects instead of nice 
>>> short-lived ones.

You also have some short-lived ones (may be about 80%?), but yes you do
have quite some (~15%?) of medium-lived ones. The total volume of
such medium-lived objects is proportional to the transactional
rate that your server is subject to, and also proportional to
the longevity of those transactions (where i am using transactions
loosely to mean how long it takes for the records associated
with those transactions to flush their state).

You mention that your application is a "reporting server".
What is your estimate of the (expected/measured)
lifetime of such a "reporting transaction"? Does it
match the kinds of object lifetimes you are seeing here?

-- ramki

 
--------------------------------------------------------------------------
This email and any files transmitted with it are confidential and proprietary to Algorithmics Incorporated and its affiliates ("Algorithmics"). If received in error, use is prohibited. Please destroy, and notify sender. Sender does not waive confidentiality or privilege. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. Algorithmics does not accept liability for any errors or omissions. Any commitment intended to bind Algorithmics must be reduced to writing and signed by an authorized signatory.
--------------------------------------------------------------------------