30593&w=2
Guy
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael Tokarev
Sent: Monday, March 14, 2005 5:47 PM
To: Arshavir Grigorian
Cc: linux-raid@vger.kernel.org; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Postgres on RAID5
Arshav
Greg Stark wrote:
Arshavir Grigorian <[EMAIL PROTECTED]> writes:
Hi,
I have a RAID5 array (mdadm) with 14 disks + 1 spare. This partition has an
Ext3 filesystem which is used by Postgres.
People are going to suggest moving to RAID1+0. I'm unconvinced that RAID5
across 14 drivers shouldn't
Arshavir Grigorian wrote:
Alex Turner wrote:
[]
Well, by putting the pg_xlog directory on a separate disk/partition, I
was able to increase this rate to about 50 or so per second (still
pretty far from your numbers). Next I am going to try putting the
pg_xlog on a RAID1+0 array and see if that h
David Dougall wrote:
In my experience, if you are concerned about filesystem performance, don't
use ext3. It is one of the slowest filesystems I have ever used
especially for writes. I would suggest either reiserfs or xfs.
I'm a bit afraid to start yet another filesystem flamewar, but.
Please don
In my experience, if you are concerned about filesystem performance, don't
use ext3. It is one of the slowest filesystems I have ever used
especially for writes. I would suggest either reiserfs or xfs.
--David Dougall
On Fri, 11 Mar 2005, Arshavir Grigorian wrote:
> Hi,
>
> I have a RAID5 arra
He doesn't have a RAID controller, it's software RAID...
Alex Turner
netEconomis
On Mon, 14 Mar 2005 16:18:00 -0500, Merlin Moncure
<[EMAIL PROTECTED]> wrote:
> Alex Turner wrote:
> > 35 Trans/sec is pretty slow, particularly if they are only one row at
> > a time. I typicaly get 200-400/sec on
Actualy my statistics were off a bit I realised - chance of failure
for one drive is 1 in X. change of failure in RAID 0 is 7 in X,
chance of one drive failure in 14 drive RAID 5 is 14 in X,13 in X for
second drive, total probably is 182 in X*X, which is much lower than
RAID 0.
Your drive perfor
Alex Turner wrote:
> 35 Trans/sec is pretty slow, particularly if they are only one row at
> a time. I typicaly get 200-400/sec on our DB server on a bad day. Up
> to 1100 on a fresh database.
Well, don't rule out that his raid controller is not caching his writes.
His WAL sync method may be ov
Alex Turner wrote:
I would recommend running a bonnie++ benchmark on your array to see if
it's the array/controller/raid being crap, or wether it's postgres. I
have had some very surprising results from arrays that theoretically
should be fast, but turned out to be very slow.
I would also seriousl
Alex Turner wrote:
a 14 drive stripe will max out the PCI bus long before anything else,
the only reason for a stripe this size is to get a total accessible
size up. A 6 drive RAID 10 on a good controller can get up to
400Mb/sec which is pushing the limit of the PCI bus (taken from
offical 3ware 9
t: 14 Mar 2005 15:17:11 -0500
Subject: Re: [PERFORM] Postgres on RAID5
> Alex Turner <[EMAIL PROTECTED]> writes:
>
> > a 14 drive stripe will max out the PCI bus long before anything else,
>
> Hopefully anyone with a 14 drive stripe is using some combination of 64 bit
>
Alex Turner <[EMAIL PROTECTED]> writes:
> a 14 drive stripe will max out the PCI bus long before anything else,
Hopefully anyone with a 14 drive stripe is using some combination of 64 bit
PCI-X cards running at 66Mhz...
> the only reason for a stripe this size is to get a total accessible
> siz
a 14 drive stripe will max out the PCI bus long before anything else,
the only reason for a stripe this size is to get a total accessible
size up. A 6 drive RAID 10 on a good controller can get up to
400Mb/sec which is pushing the limit of the PCI bus (taken from
offical 3ware 9500S 8MI benchmarks
Josh Berkus wrote:
A,
This is a Sun e450 with dual TI UltraSparc II processors and 2G of RAM.
It is currently running Debian Sarge with a 2.4.27-sparc64-smp custom
compiled kernel. Postgres is installed from the Debian package and uses
all the configuration defaults.
Please read http://www.powerp
Arshavir Grigorian <[EMAIL PROTECTED]> writes:
> Hi,
>
> I have a RAID5 array (mdadm) with 14 disks + 1 spare. This partition has an
> Ext3 filesystem which is used by Postgres.
People are going to suggest moving to RAID1+0. I'm unconvinced that RAID5
across 14 drivers shouldn't be able to kee
Hi Arshavir Grigorian,
0. If possible move to 8.0.1 - bgwriter help you
1. Create RAID1 for redo and place drives on separate
SCSI channel
2. Update postgresql.conf:
shared_buffers = 1-5
work_mem = 10-30
maintenance_work_mem = 10-30
max_fsm_pages = 150
max
On Fri, 11 Mar 2005 16:13:05 -0500, Arshavir Grigorian <[EMAIL PROTECTED]> wrote:
Hi,
I have a RAID5 array (mdadm) with 14 disks + 1 spare. This partition has
an Ext3 filesystem which is used by Postgres. Currently we are loading a
50G database on this server from a Postgres dump (copy, not ins
I would recommend running a bonnie++ benchmark on your array to see if
it's the array/controller/raid being crap, or wether it's postgres. I
have had some very surprising results from arrays that theoretically
should be fast, but turned out to be very slow.
I would also seriously have to recommen
Look for the possibility that a foreign key check might not be using an
index. This would yield a seq scan for each insertion, which might be your
problem.
On Fri, 11 Mar 2005 19:22:56 -0500, Arshavir Grigorian <[EMAIL PROTECTED]>
wrote:
Many thanks for all the response.
I guess there are
A,
> This is a Sun e450 with dual TI UltraSparc II processors and 2G of RAM.
> It is currently running Debian Sarge with a 2.4.27-sparc64-smp custom
> compiled kernel. Postgres is installed from the Debian package and uses
> all the configuration defaults.
Please read http://www.powerpostgresql.c
Many thanks for all the response.
I guess there are a lot of things to change and tweak and I wonder what
would be a good benchmarking sample dataset (size, contents).
My tables are very large (the smallest is 7+ mil records) and take
several days to load (if not weeks). It would be nice to have
Arshavir Grigorian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> How are you measuring that write rate (seeing that pg_restore doesn't
>> provide any such info)?
> Well, if the restore is going on for X number of hours and you have Y
> records loaded, it's not hard to ballpark.
Yeah, but how
On Fri, Mar 11, 2005 at 05:29:11PM -0500, Arshavir Grigorian wrote:
> Tom Lane wrote:
> >The defaults are made for a fairly small machine, not big iron. At a
> >minimum you want to kick shared_buffers up to 10K or more.
> >
> Will do. Thanks.
Also, it may help that you bump up sort_mem while doi
Tom Lane wrote:
Arshavir Grigorian <[EMAIL PROTECTED]> writes:
I have a RAID5 array (mdadm) with 14 disks + 1 spare. This partition has
an Ext3 filesystem which is used by Postgres. Currently we are loading a
50G database on this server from a Postgres dump (copy, not insert) and
are experiencing v
Arshavir Grigorian <[EMAIL PROTECTED]> writes:
> I have a RAID5 array (mdadm) with 14 disks + 1 spare. This partition has
> an Ext3 filesystem which is used by Postgres. Currently we are loading a
> 50G database on this server from a Postgres dump (copy, not insert) and
> are experiencing very slow
25 matches
Mail list logo
