DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=LFiXmWc8cnRiPnPEvihKcsf26rVlSv0rF6BxnlROzEoqhX9wn8F3cO48VWDWH1t90F6gnbiFEZO5hkyBAQbwrF7JvJVjuv4ezpduXAgCWBGk46jeYyDhBDbIU/922ZP5XNKXeRAnlBT4S55B/PxV4cKYYdDUyAhuvb//QhmjCUI=;
Message-ID: <81350.2353.qm@web111304.mail.gq1.yahoo.com>
Date: Wed, 8 Dec 2010 15:26:57 -0800 (PST)
From: Andy <angelflow@yahoo.com>
Subject: Re: Hardware recommendations
To: pgsql-performance@postgresql.org, Benjamin Krajmalnik <kraj@servoyant.com>
In-Reply-To: <F4E6A2751A2823418A21D4A160B689887B0A4D@fletch.stackdump.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

If you are IO-bound, you might want to consider using SSD.=0A=0AA single SS=
D could easily give you more IOPS than 16 15k SAS in RAID 10.=0A =0A--- On =
Wed, 12/8/10, Benjamin Krajmalnik <kraj@servoyant.com> wrote:=0A=0A> From: =
Benjamin Krajmalnik <kraj@servoyant.com>=0A> Subject: [PERFORM] Hardware re=
commendations=0A> To: pgsql-performance@postgresql.org=0A> Date: Wednesday,=
 December 8, 2010, 6:03 PM=0A> I need to build a new high=0A> performance s=
erver to replace our current production=0A> database server.=0A> The curren=
t server is a SuperMicro 1U with 2 RAID-1=0A> containers (one for data, one=
 for log, SAS - data is 600GB,=0A> Logs 144GB), 16GB of RAM, running 2 quad=
 core processors=0A> (E5405 @ 2GHz), Adaptec 5405 Controller with BBU.=A0 I=
 am=0A> already having serious I/O bottlenecks with iostat -x=0A> showing e=
xtended periods where the disk subsystem on the=0A> data partition (the one=
 with all the random i/o) at over 85%=0A> busy.=A0 The system is running Fr=
eeBSD 7.2 amd64 and=0A> PostgreSQL 8.4.4 on amd64-portbld-freebsd7.2, compi=
led by=0A> GCC cc (GCC) 4.2.1 20070719=A0 [FreeBSD], 64-bit.=0A> Currently =
I have about 4GB of shared memory allocated to=0A> PostgreSQL.=A0 Database =
is currently about 80GB, with about=0A> 60GB being in partitioned tables wh=
ich get rotated nightly=0A> to purge old data (sort of like a circular buff=
er of=0A> historic data).=0A> =0A> I was looking at one of the machines whi=
ch Aberdeen has=0A> (the X438), and was planning =A0on something along the =
lines=0A> of 96GB RAM with 16 SAS drives (15K).=A0 If I create a RAID=0A> 1=
0 (stripe of mirrors), leaving 2 hot spares, should I still=0A> place the l=
ogs in a separate RAID-1 mirror, or can they be=0A> left on the same RAID-1=
0 container?=0A> On the processor front, are there advantages to going to X=
=0A> series processors as opposed to the E series (especially=0A> since I a=
m I/O bound)?=A0 Is anyone running this type of=0A> hardware, specially on =
FreeBSD?=A0 Any opinions, especially=0A> concerning the Areca controllers w=
hich they use?=0A> =0A> The new box would ideally be built with the latest =
released=0A> version of FreeBSD, PG 9.x.=A0 Also, is anyone running the=0A>=
 8.x series of FreeBSD with PG 9 in a high throughput=0A> production enviro=
nment?=A0 I will be upgrading one of our=0A> test servers in one week to th=
is same configuration to test=0A> out, but just wanted to make sure there a=
ren't any caveats=0A> others have experienced, especially as it pertains wi=
th the=0A> autovacuum not launching worker processes which I have=0A> exper=
ienced.=0A> =0A> Best regards,=0A> =0A> Benjamin =0A> =0A> -- =0A> Sent via=
 pgsql-performance mailing list (pgsql-performance@postgresql.org)=0A> To m=
ake changes to your subscription:=0A> http://www.postgresql.org/mailpref/pg=
sql-performance=0A> =0A=0A=0A