pgbench results

HI,

HAS ANYONE BEEN ABLE TO REPLICATE RESULTS FROM
HTTP://WWW.KALTENBRUNNER.CC/BLOG/INDEX.PHP?/ARCHIVES/21-GUID
.HTML, OR
GET CLOSE TO THE PERFORMANCE DESCRIBED THERE ON SIMILAR
HARDWARE (E.G.
THOUSANDS OF TRANSACTIONS/S) ?

--- Ivan Voras <ivorasfreebsd.org> wrote:

> Hi,
> 
> Has anyone been able to replicate results from
>
http://www.kaltenbrunner.cc/blog/index.php?/arc
hives/21-guid.html,
> or
> get close to the performance described there on
> similar hardware (e.g.
> thousands of transactions/s) ?
> 

Here's mine for a somewhat similar setup.  
FreeBSD 7.0 PostgreSQL 8.3
2x Intel Xeon 2.33GHZ quad cores (8 cores total), 8GB
RAM, 250GB RAID 10 (4x WD Raptor 10K drives).

Non-default settings: 

                        
max_connections = 200 
shared_buffers = 1900MB
wal_buffers = 1024kB
checkpoint_segments = 192             
checkpoint_timeout = 30min 

 

createdb testdb
pgbench -i -s 100 testdb

# pgbench -c 100 -t 100000 testdb
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 100
number of transactions per client: 100000
number of transactions actually processed:
10000000/10000000
tps = 1650.806584 (including connections establishing)
tps = 1650.905036 (excluding connections establishing)

So, not as high as his numbers but then I've got less
RAM, one less drive spindle in my array (2 vs. 3 in
performance for the raid 10 setup), SATA vs. SCSI,
he's got 512MB of controller cache vs my 128MB.

--Alan



     
____________________________________________________________
________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9
tAcJ 

_______________________________________________
freebsd-performancefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-p
erformance
To unsubscribe, send any mail to
"freebsd-performance-unsubscribefreebsd.org"

HTTP://WWW.KALTENBRUNNER.CC/BLOG/INDEX.PHP?/ARCHIVES/21-GUID
.HTML

ALAN BRYAN WROTE:

> HERE'S MINE FOR A SOMEWHAT SIMILAR SETUP.  
> FREEBSD 7.0 POSTGRESQL 8.3
> 2X INTEL XEON 2.33GHZ QUAD CORES (8 CORES TOTAL), 8GB
> RAM, 250GB RAID 10 (4X WD RAPTOR 10K DRIVES).
> 
> NON-DEFAULT SETTINGS: 
> 
>                         
> MAX_CONNECTIONS = 200 
> SHARED_BUFFERS = 1900MB
> WAL_BUFFERS = 1024KB
> CHECKPOINT_SEGMENTS = 192             
> CHECKPOINT_TIMEOUT = 30MIN 
> 
> CREATEDB TESTDB
> PGBENCH -I -S 100 TESTDB
> 
> # PGBENCH -C 100 -T 100000 TESTDB
> STARTING VACUUM...END.
> TRANSACTION TYPE: TPC-B (SORT OF)
> SCALING FACTOR: 100
> NUMBER OF CLIENTS: 100
> NUMBER OF TRANSACTIONS PER CLIENT: 100000
> NUMBER OF TRANSACTIONS ACTUALLY PROCESSED:
> 10000000/10000000
> TPS = 1650.806584 (INCLUDING CONNECTIONS ESTABLISHING)
> TPS = 1650.905036 (EXCLUDING CONNECTIONS ESTABLISHING)
> 
> SO, NOT AS HIGH AS HIS NUMBERS BUT THEN I'VE GOT LESS
> RAM, ONE LESS DRIVE SPINDLE IN MY ARRAY (2 VS. 3 IN
> PERFORMANCE FOR THE RAID 10 SETUP), SATA VS. SCSI,
> HE'S GOT 512MB OF CONTROLLER CACHE VS MY 128MB.

THE THING IS - I *DO* HAVE A SIMILAR SETUP HERE: HP DL370
G5, 2X4-CORE
1.86 GHZ, 4 GB RAM, 6 DRIVES IN RAID10, 512 MB CACHE (CAN
PULL > 200
MB/S OFF THE ARRAY), WITH ALL SETTINGS LIKE IN THE POSTED
LINK EXCEPT
SHARED_BUFFER=1900 MB, AND I "ONLY" GET THIS:

TPS = 2834.026175 (INCLUDING CONNECTIONS ESTABLISHING)
TPS = 2839.080739 (EXCLUDING CONNECTIONS ESTABLISHING)

THIS IS STILL FAR BELLOW ~~ 4500 TRANS/S FROM THE LINK AND I
WONDER IF
MY RESULTS ARE WITHIN WHAT I SHOULD BE GETTING. THE
BENCHMARK IN THE
LINK ABOVE WAS DONE WITH FASTER CPUS (BUT I'M NOT CPU BOUND
- AT LEAST
30% IDLE), BUT WITH 3 TIMES THE MEMORY AND I'M GUESSING MORE
MEMORY
WOULD HELP HERE, BUT I'M NOT SURE.

WHAT'S STRANGE IS THAT TOGGLING SYNCHRONOUS_COMMIT DOESN'T
HAVE A
SIGNIFICANT EFFECT ON PERFORMANCE (IT DOES INCREASE CPU IDLE
TIME). WITH
SYNCHRONOUS_COMMIT=OFF, I GET:

TPS = 2886.980477 (INCLUDING CONNECTIONS ESTABLISHING)
TPS = 2891.776081 (EXCLUDING CONNECTIONS ESTABLISHING)

Ivan Voras wrote:
>
> The thing is - I *do* have a similar setup here: HP
DL370 G5, 2x4-core
> 1.86 GHz, 4 GB RAM, 6 drives in RAID10, 512 MB cache
(can pull > 200
> MB/s off the array), with all settings like in the
posted link except
> shared_buffer=1900 MB, and I "only" get
this:
>
> tps = 2834.026175 (including connections establishing)
> tps = 2839.080739 (excluding connections establishing)
>
> This is still far bellow ~~ 4500 trans/s from the link
and I wonder if
> my results are within what I should be getting. The
benchmark in the
> link above was done with faster CPUs (but I'm not CPU
bound - at least
> 30% idle), but with 3 times the memory and I'm guessing
more memory
> would help here, but I'm not sure.
>
> What's strange is that toggling synchronous_commit
doesn't have a
> significant effect on performance (it does increase CPU
idle time). With
> synchronous_commit=off, I get:
>
> tps = 2886.980477 (including connections establishing)
> tps = 2891.776081 (excluding connections establishing)
>
>   

The article refers to a controller with a battery backed
write cache - 
that could easily explain the difference if you do not have
one (he's 
paying nothing for fsync wheres you are).

regards

Mark
_______________________________________________
freebsd-performancefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-p
erformance
To unsubscribe, send any mail to
"freebsd-performance-unsubscribefreebsd.org"

Mark Kirkwood wrote:
> Ivan Voras wrote:
>>
>> The thing is - I *do* have a similar setup here: HP
DL370 G5, 2x4-core
>> 1.86 GHz, 4 GB RAM, 6 drives in RAID10, 512 MB
cache (can pull > 200
>> MB/s off the array), with all settings like in the
posted link except
>> shared_buffer=1900 MB, and I "only" get
this:
>>
>> tps = 2834.026175 (including connections
establishing)
>> tps = 2839.080739 (excluding connections
establishing)
>>
>> This is still far bellow ~~ 4500 trans/s from the
link and I wonder if
>> my results are within what I should be getting. The
benchmark in the
>> link above was done with faster CPUs (but I'm not
CPU bound - at least
>> 30% idle), but with 3 times the memory and I'm
guessing more memory
>> would help here, but I'm not sure.
>>
>> What's strange is that toggling synchronous_commit
doesn't have a
>> significant effect on performance (it does increase
CPU idle time). With
>> synchronous_commit=off, I get:
>>
>> tps = 2886.980477 (including connections
establishing)
>> tps = 2891.776081 (excluding connections
establishing)
>>
>>   
>
> The article refers to a controller with a battery
backed write cache - 
> that could easily explain the difference if you do not
have one (he's 
> paying nothing for fsync wheres you are).
>

Hmm - somehow read right past the bit where you say you have
a 512MB 
cache - sorry! However, worth checking it is set to
write-back rather 
than write-through.

Cheers

Mark
_______________________________________________
freebsd-performancefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-p
erformance
To unsubscribe, send any mail to
"freebsd-performance-unsubscribefreebsd.org"

On 12/03/2008, Mark Kirkwood <markirparadise.net.nz> wrote:

> Hmm - somehow read right past the bit where you say you
have a 512MB
>  cache - sorry! However, worth checking it is set to
write-back rather
>  than write-through.

As far as I can see it is set to write-through (though the
HP's array
configuration utility isn't explicit about it, everything
performance-wise than can be turned on is turned on,
including write
cache).
_______________________________________________
freebsd-performancefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-p
erformance
To unsubscribe, send any mail to
"freebsd-performance-unsubscribefreebsd.org"

On Wed, 12 Mar 2008, Ivan Voras wrote:

> On 12/03/2008, Mark Kirkwood <markirparadise.net.nz> wrote:
>
>> Hmm - somehow read right past the bit where you say
you have a 512MB
>>  cache - sorry! However, worth checking it is set
to write-back rather
>>  than write-through.
>
> As far as I can see it is set to write-through (though
the HP's array
> configuration utility isn't explicit about it,
everything
> performance-wise than can be turned on is turned on,
including write
> cache).

What kernel are you running?

> _______________________________________________
> freebsd-performancefreebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-p
erformance
> To unsubscribe, send any mail to
"freebsd-performance-unsubscribefreebsd.org"
>
_______________________________________________
freebsd-performancefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-p
erformance
To unsubscribe, send any mail to
"freebsd-performance-unsubscribefreebsd.org"

On 13/03/2008, Jeff Roberson <jrobersonchesapeake.net> wrote:
>
>  On Wed, 12 Mar 2008, Ivan Voras wrote:
>
>  > On 12/03/2008, Mark Kirkwood <markirparadise.net.nz> wrote:
>  >
>  >> Hmm - somehow read right past the bit where
you say you have a 512MB
>  >>  cache - sorry! However, worth checking it is
set to write-back rather
>  >>  than write-through.
>  >
>  > As far as I can see it is set to write-through
(though the HP's array
>  > configuration utility isn't explicit about it,
everything
>  > performance-wise than can be turned on is turned
on, including write
>  > cache).
>
> What kernel are you running?

7-STABLE since Feb 29, amd64+ULE.
_______________________________________________
freebsd-performancefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-p
erformance
To unsubscribe, send any mail to
"freebsd-performance-unsubscribefreebsd.org"