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
Folks,
> You said:
> "If your write size is smaller than chunk_size*N (N = number
> of data blocks in a stripe), in order to calculate correct
> parity you have to read data from the remaining drives."
>
> Neil explained it in this message:
> http://marc.theaimsgroup.com/?l=linux-raid&m=1086821
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,
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 write performance (35 records per second).
Top
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
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 insert) and
are experiencing very slow write performance (35 records per second).
Top sho
28 matches
Mail list logo
