Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Fri, 19 Aug 2005 11:17:20 +0200
From: Oystein.Grovlen@Sun.COM (=?iso-8859-1?q?=D8ystein_Gr=F8vlen?=)
Subject: Re: Can anyone give me some suggestions?
In-reply-to: <4304FC92.90707@sbcglobal.net>
To: Derby Development <derby-dev@db.apache.org>
Message-id: <x1ofbr3u1e1r.fsf@atum11.norway.sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8BIT
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2
Lines: 34
References: <BAY17-F218527600161688A347F279AB20@phx.gbl>
 <4304FC92.90707@sbcglobal.net>

>>>>> "MM" == Mike Matrigali <mikem_app@sbcglobal.net> writes:

    MM> As Oystein says I think the main reason to tune checkpoint interval is
    MM> some sort of balance between recovery time and performance overhead of
    MM> the checkpoint.  The last change in this area bumped the log file size
    MM> from 100k to 1 meg, and the checkpoint size from 1 log file to 10 log
    MM> files.  Even this change makes us do many more checkpoints than
    MM> competing databases, especially in benchmark situations when other dbs
    MM> don't do any checkpoints.  Some time based approach may be interesting,
    MM> with inputs of how long does a checkpoint take and how long since the
    MM> last checkpoint and total log volume rate. There is also the log file
    MM> garbage collection issue.

It would be interesting to see a study of how different settings for
the checkpoint interval impact throughput and recovery times.  That
seems like well suited for a student project.


    MM> I don't think checkpointing is the way to control # dirty pages in the
    MM> cache.  The current system tries to do this in the clock algorithm, by
    MM> having a background thread "clean" dirty pages when it thinks there
    MM> are too many.  This buffer cache, clock algorithm is pretty simple so
    MM> there may be improvements possible there - I believe some have already
    MM> been discussed on the list with respect to weighting various
    MM> pages.  

OK, I was not aware of this mechanism.  I guess the benefit of having
two mechanisms that write pages to disk is that the clock algorithm
only writes those pages that are likely to soon be thrown of the
cache.  Hence, hot spot pages are normally only written at each
checkpoint.

-- 
�ystein