pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: John Rouillard <rouilj@renesys.com>
To: Wayne Conrad <wayne@databill.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Are we in the ballpark?
Date: Wed, 2 Feb 2011 19:51:01 +0000
Message-ID: <20110202195101.GM2027@renesys.com> (raw)
In-Reply-To: <4D498F2D.2030501@databill.com>
References: <4D48A3E6.6080904@databill.com>
	<4D48B3AC.206@2ndquadrant.com>
	<4D498F2D.2030501@databill.com>

On Wed, Feb 02, 2011 at 10:06:53AM -0700, Wayne Conrad wrote:
> On 02/01/11 18:30, Greg Smith wrote:
> >>Bonnie++ (-f -n 0 -c 4)
> >>$PGDATA/xlog (RAID1)
> >>random seek: 369/sec
> >>block out: 87 MB/sec
> >>block in: 180 MB/sec
> >>$PGDATA (RAID10, 12 drives)
> >>random seek: 452
> >>block out: 439 MB/sec
> >>block in: 881 MB/sec
> >>
> >>sysbench test of fsync (commit) rate:
> >>
> >>$PGDATA/xlog (RAID1)
> >>cache off: 29 req/sec
> >>cache on: 9,342 req/sec
> >>$PGDATA (RAID10, 12 drives)
> >>cache off: 61 req/sec
> >>cache on: 8,191 req/sec
> >
> >That random seek rate is a little low for 12 drives, but that's probably
> >the limitations of the 3ware controller kicking in there. Your "cache
> >off" figures are really weird though; I'd expect those both to be around
> >100. Makes me wonder if something weird is happening in the controller,
> >or if there was a problem with your config when testing that. Not a big
> >deal, really--the cached numbers are normally going to be the important
> >ones--but it is odd.
> 
> I also thought the "cache off" figures were odd.  I expected
> something much closer to 120 req/sec (7200 rpm drives).  I probably
> won't investigate that with any vigor, since the cache-on numbers
> are OK.

You may want to look into the "cache off" figures a little more. We
run a number of battery backed raid controllers and we test the
batteries every 6 months or so. When we test the batteries, the cache
goes off line (as it should) to help keep the data valid.

If you need to test your raid card batteries (nothing like having a
battery with only a 6 hour runtime when it takes you a couple of days
MTTR), can your database app survive with that low a commit rate? As
you said you ar expecting something almost 4-5x faster with 7200 rpm
disks.

-- 
				-- rouilj

John Rouillard       System Administrator
Renesys Corporation  603-244-9084 (cell)  603-643-9300 x 111



view thread (4+ messages)

Message-ID: <20110202195101.GM2027@renesys.com>
Permalink:  ../20110202195101.GM2027@renesys.com/
Also on:    postgresql.org/message-id/20110202195101.GM2027@renesys.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: rouilj@renesys.com, wayne@databill.com
  Subject: Re: Are we in the ballpark?
  In-Reply-To: <20110202195101.GM2027@renesys.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox