All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Greaves <david@dgreaves.com>
To: Greg Stark <gsstark@mit.edu>
Cc: Arshavir Grigorian <ag@m-cam.com>,
	linux-raid@vger.kernel.org, pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Postgres on RAID5 (possible sync blocking read type issue on 2.6.11)
Date: Mon, 14 Mar 2005 07:44:53 +0000	[thread overview]
Message-ID: <423540F5.8090609@dgreaves.com> (raw)
In-Reply-To: <87hdje7sjm.fsf@stark.xeocode.com>

Greg Stark wrote:

>Arshavir Grigorian <ag@m-cam.com> 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 keep up with RAID1 across 7 drives
>though. It would be interesting to see empirical data.
>
>One thing that does scare me is the Postgres transaction log and the ext3
>journal both sharing these disks with the data. Ideally both of these things
>should get (mirrored) disks of their own separate from the data files.
>
>But 2-3s pauses seem disturbing. I wonder whether ext3 is issuing a cache
>flush on every fsync to get the journal pushed out. This is a new linux
>feature that's necessary with ide but shouldn't be necessary with scsi.
>
>It would be interesting to know whether postgres performs differently with
>fsync=off. This would even be a reasonable mode to run under for initial
>database loads. It shouldn't make much of a difference with hardware like this
>though. And you should be aware that running under this mode in production
>would put your data at risk.
>
Hi
I'm coming in from the raid list so I didn't get the full story.

May I ask what kernel?

I only ask because I upgraded to 2.6.11.2 and happened to be watching 
xosview on my (probably) completely different setup (1Tb xfs/lvm2/raid5 
served by nfs to a remote sustained read/write app), when I saw all read 
activity cease for 2/3 seconds whilst the disk wrote, then disk read 
resumed. This occured repeatedly during a read/edit/write of a 3Gb file.

Performance not critical here so on the "hmm, that's odd" todo list :)

David


  reply	other threads:[~2005-03-14  7:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-11 19:48 Postgres on RAID5 Arshavir Grigorian
2005-03-14  4:36 ` [PERFORM] " Greg Stark
2005-03-14  7:44   ` David Greaves [this message]
2005-03-14 19:53   ` Alex Turner
2005-03-14 20:17     ` Greg Stark
2005-03-14 20:35       ` Jim Buttafuoco
2005-03-14 21:03     ` Arshavir Grigorian
2005-03-14 22:47       ` Michael Tokarev
2005-03-14 23:49         ` Guy
2005-03-15 16:17           ` Effect of Stripe Size (was Postgres on RAID5) Ruth Ivimey-Cook
2005-03-16 16:47 ` Postgres on RAID5 David Dougall
2005-03-16 16:55   ` Michael Tokarev

Reply instructions:

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

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

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=423540F5.8090609@dgreaves.com \
    --to=david@dgreaves.com \
    --cc=ag@m-cam.com \
    --cc=gsstark@mit.edu \
    --cc=linux-raid@vger.kernel.org \
    --cc=pgsql-performance@postgresql.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.