db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: [jira] Assigned: (DERBY-1664) Derby startup time is too slow
Date Fri, 11 Aug 2006 16:16:15 GMT
Ah, yes, the write cache, I wrote about it here:

http://weblogs.java.net/blog/davidvc/archive/2005/10/the_story_of_th.html

But I wrote this after hearing about this issue from folks in our 
performance team.  I have never personally had to investigate and 
enable/disable the write cache on a system, so I'm flying a bit blind. 
Checking with our Solaris guys, but if anybody has the answer for Linux 
that would be great.  Maybe we can put it on a Wiki page somewhere :)

David

Mike Matrigali wrote:
> 
> 
> 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:
>>
> 

Mime
View raw message