Hi Mike,
A question totally on the side of this discussion: Do you, or anyone
else, have any opinion about how the "runtime performance" of Derby
would be affected by not having checkpoints at all, say for a large
database (around 20 GB) and 0.5 GB of page cache in a disk-bound
application load?
Is the Derby background-writer (and Clock.java) written/designed to
handle such "extreme cases" without major performance degradation?
Any information on the goal/function of the background-writer?
What mechanisms would kick in when the page-cache is full and Derby
needs slots for new pages?
I do know this is not a smart way to handle things, I'm just curious
what people think about this! And I am not seeking answers about long
recovery times and log disk space usage ;)
--
Kristian
Mike Matrigali wrote:
I think this is the right path, though would need more details:
o does boot mean first time boot for each db?
o how to determine "this machine"
o and the total time to run such a test.
There are some very quick and useful tests that would be fine to
add to the default system and do one time per database Measureing
how long to do a commit and how long to do a single database read from
disk would be fine. Seems like
just these 2 numbers could be used to come up with a very good
default estimate of log recovery time per log record. Then as you
propose the actual estimate can be improved by meauring real
recovery time in the future.
I am not convinced of the need for the bigger test, but if the default
is not to run it automatically and it is your "itch" to have such
a configuration option then I would not oppose. I do see great value
in coming up with a very good default estimate of recovery time estimate
based on outstanding number of log records. And
I even envision
a framework in the future where derby would schedule other non-essential
background tasks that have been discussed in the
On a different track I am still unclear on the checkpoint dirty page
lru list. Rather than talk about implementation details, I would
like to understand the problem you are trying to solve. For instance
I well understand the goal to configure checkpoints such that they
map to user understandable concept of the tradeoff of current runtime
performance vs. how long am I willing to wait the next time I boot
the database after a crash.
What is the other problem you are looking at.
Raymond Raymond wrote:
Mike,
Last time we discussed about how to map the recovery time into Xmb of log.
I have been thinking on it recently and have a proposal.
How about when the very first time derby boots (not every time) on a
certain
machine, we let the user to chose whether he (or she) want to do some
statistic
collection about the system performance. If he (or she) want to do,
derby runs
some test, if not, derby doesn't run test. Later, just as what you said,
we let derby
collect information every time it does recovery to refine the former
information.
Thanks.
Raymond
_________________________________________________________________
Don’t just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
