Skip site navigation (1) Skip section navigation (2)

Re: Advice sought : new database server

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Rory Campbell-Lange <rory(at)campbell-lange(dot)net>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Advice sought : new database server
Date: 2012-03-04 19:49:57
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Sun, Mar 4, 2012 at 11:36 AM, Rory Campbell-Lange
<rory(at)campbell-lange(dot)net> wrote:
> On 04/03/12, Scott Marlowe (scott(dot)marlowe(at)gmail(dot)com) wrote:

>> The 15k RPM disks aren't that big of a deal unless you're pushing the
>> bleeding edge on a transactional system. I'm gonna take a wild guess
>> that you're not doing heavy transactions, in which case, the BBU on
>> the areca is the single most important thing for you to get for good
>> performance.  The areca 1880 is a great controller and is much much
>> easier to configure than the LSI.  Performance wise it's one of the
>> fastest DAS controllers made.
> We do have complex transactions, but I haven't benchmarked the
> performance so I can't describe it.

Yeah try to get a measurement of how many transactions per second
you're running at peak load, and if you're currently IO bound or CPU

> Few of the databases are at the many
> million row size at the moment, and we are moving to an agressive scheme
> of archiving old data, so we hope to keep things fast.

The key here is that your whole db can fit into memory.  48G is
cutting it close if you're figuring on being at 40G in a year.  I'd
spec it out with 96G to start.  That way if you want to set work_mem
to 8 or 16M you can without worrying about running the machine out of
memory / scramming your OS file system cache with a few large queries

> However I thought 15k disks were a pre-requisite for a fast database
> system, if one can afford them?

The heads have to seek, settle and THEN you ahve to wait for the
platters to rotate under the head i.e. latency.

> I assume if all else is equal the 1880
> controller will run 20-40% faster with 15k disks in a write-heavy
> application.
> Also I would be grateful to learn if there is a good reason
> not to use 2.5" SATA disks.

The 10k 2.5 seagate drives have combined seek and latency figures of
about 7ms, while the15k 2.5 seagate drives have a combined time of
about 5ms.  Even the fastest 3.5" seagates average 6ms average seek
time, but with short stroking can get down to 4 or 5.

Now all of this becomes moot if you compare them to SSDs, where the
seek settle time is measured in microseconds or lower.  The fastest
spinning drive will look like a garbage truck next to the formula one
car that is the SSD.  Until recently incompatabilites with RAID
controllers and firmware bugs kept most SSDs out of the hosting
center, or made the ones you could get horrifically expensive.  The
newest generations of SSDs though seem to be working pretty well.

>> If the guys you're looking at getting this from can't do custom
>> orders, find a white box dealer who can, like  It
>> might not be on their site, but they can build dang near anything you
>> want.
> Thanks for the note about Aberdeen. I've seen the advertisements, but
> not tried them yet.

There's lots of others to choose from.  In the past I've gotten
fantastic customer service from aberdeen, and they've never steered me
wrong.  I've had my sales guy simply refuse to sell me a particular
drive because the failure rate was too high in the field, etc.  They
cross ship RAID cards overnight, and can build truly huge DAS servers
if you need them.  Like a lot of white box guys they specialize more
in large storage arrays and virualization hardware, but there's a lot
of similarity between that class of machine and a db server.

In response to


pgsql-performance by date

Next:From: Scott MarloweDate: 2012-03-04 19:51:41
Subject: Re: Advice sought : new database server
Previous:From: Andy ColsonDate: 2012-03-04 19:45:38
Subject: Re: Advice sought : new database server

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group