db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Øystein Grøvlen <Oystein.Grov...@Sun.COM>
Subject Re: performance issue
Date Thu, 16 Oct 2008 19:46:28 GMT

Jonas Ahlinder wrote:
> The benchmark client is single-threaded atm.
> To run it multi-threaded some sort of locking will most likely have ot me implemented
( which will be done as soon as we can confirmt he performance is ok ).
> I have tried running more threads, and it does seem to give better performance, but the
current state of the client doesnt really allow for reliable testresults.
> With autocommit on, and with the disk running 100% usage ( and quite a bit of wait queue
at least on Linux ) do you think multiple threads will really help ?
> And CPU ( 4 cores ) seem to run about 50% wait and 50% idle, which seems rather wierd
to me, but i guess its mostly waiting for IO.

Which disk is running at 100% usage?  The data disk or the log disk?
If it is the log disk that is saturated, having multiple threads may 
help throughput because then it will be possible to commit multiple 
transactions per disk write.


> ________________________________________
> From: Bryan Pendleton [bpendleton@amberpoint.com]
> Sent: Thursday, October 16, 2008 5:43 PM
> To: Derby Discussion
> Subject: Re: performance issue
>>> The first issue is that on a desktop machine ( running vista ) with
>>> two 7.2k rpm sata disks I get over 900 tps, while on a server (
>>> running RHEL 5 ) and two 15k rpm sas disks, I get around 250 tps.
> Is your benchmark client multi-threaded? Or single-threaded?
> During the run(s) are your machine(s) CPU-bound? Or disk-bound?
> thanks,
> bryan

View raw message