Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Wed, 01 Feb 2006 23:17:13 +0100
From: Kristian Waagan <Kristian.Waagan@Sun.COM>
Subject: Re: Discussion of how to map the recovery time into Xmb of log
 --Checkpoint issue
In-reply-to: <43E10A09.2070602@sbcglobal.net>
To: derby-dev@db.apache.org
Message-id: <43E13369.9050801@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=windows-1252; format=flowed
Content-transfer-encoding: 8BIT
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923)
References: <BAY113-F24C575D787895BA81478149A0B0@phx.gbl>
 <43E10A09.2070602@sbcglobal.net>

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/
>>
>>
>>    
>>