Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <44DC97CC.7010008@sbcglobal.net>
Date: Fri, 11 Aug 2006 07:44:28 -0700
From: Mike Matrigali <mikem_app@sbcglobal.net>
Reply-To: mikem_app@sbcglobal.net
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: [jira] Assigned: (DERBY-1664) Derby startup time is too slow
References: <21233852.1155248954791.JavaMail.jira@brutus>
 <44DBC695.1060303@sbcglobal.net> <44DBCB1D.6060103@sun.com>
In-Reply-To: <44DBCB1D.6060103@sun.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


David Van Couvering wrote:
> Hi, Mike.  Thanks for wanting to participate.  My first step I was 
> planning to do was to do some measurements, as you suggested.
> 
> I was going to start with my own machine, which is a laptop running 
> Solaris x86.  But I suspect a lot of folks care about XP and Linux.  I 
> can create a test and we can run it on different machines and see what 
> the variance is.
> 
> I was thinking of doing a test that measures startup time with creating 
> a new db and using an existing one as the first step.  I was then going 
> to refine from there.
> 
> Dumb sysadmin question: on Solaris, XP, and Linux, how do you find out 
> if your system is syncing to disk or not?
I am not sure on solaris/linux.  On XP it is a path through the hardware
manager/device manager down the device drop downs - I will see if I have
it. But probably the easiest is to write a test with one row keyed row
in a table with an int data column and run an autocommit loop updating
the single column.  If you get ~100 xacts a second (dependent on disk
speed), then syncing is happening.  If you get much higher, like 1000 
then no syncing.

Many of the db's we get compared to, don't even do syncs by default
leading to the perception issue.

To understand the numbers this will catch also hardware where syncing
is "correct" but abnormally fast.  we have a machine that hardware
caches synced writes - so syncs are instantaneous unless the cache 
fills, but since it has a battery backup and software
to flush writes it is not "improper" - but still important to understand 
as not a normal case for many low end systems.
> 
> Thanks,
> 
> David
> 
> P.S. I'm not prepared to have the discussion about copying from a model 
> database at this time.  Let's just first find out what's going on...
> 
> Mike Matrigali wrote:
>