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