pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedLVM and Postgres
8+ messages / 5 participants
[nested] [flat]
* LVM and Postgres
@ 2005-12-06 09:38 Rory Campbell-Lange <rory@campbell-lange.net>
0 siblings, 1 reply; 8+ messages in thread
From: Rory Campbell-Lange @ 2005-12-06 09:38 UTC (permalink / raw)
To: pgsql-performance
I need to slice up a web server's disk space to provide space for
postgres and storing binaries such as images and sound files. I'm
thinking of using logical volume management (LVM) to help manage the
amount of space I use between postgres and the data volumes.
The server has a 250GB RAID10 (LSI 320-I + BBU) volume which I am
thinking of slicing up in the following way (Linux 2.6 kernel):
/ : ext3 : 47GB (root, home etc)
/boot : ext3 : 1GB
/tmp : ext2 : 2GB
/usr : ext3 : 4GB
/var : ext3 : 6GB
-----------------------
60GB
VG : 190GB approx
-----------------------
Initially divided so:
/data : ext3 : 90GB
/postgres : xfs : 40GB
This gives me left over space of roughly 60GB to extend into on the
volume group, which I can balance between the /data and /postgres
logical volumes as needed.
Are there any major pitfalls to this approach?
Thanks,
Rory
--
Rory Campbell-Lange
<rory@campbell-lange.net>
<www.campbell-lange.net>
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: LVM and Postgres
@ 2005-12-06 20:12 August Zajonc <augustz@augustz.com>
parent: Rory Campbell-Lange <rory@campbell-lange.net>
0 siblings, 1 reply; 8+ messages in thread
From: August Zajonc @ 2005-12-06 20:12 UTC (permalink / raw)
To: pgsql-performance
Rory Campbell-Lange wrote:
> The server has a 250GB RAID10 (LSI 320-I + BBU) volume which I am
> thinking of slicing up in the following way (Linux 2.6 kernel):
>
> / : ext3 : 47GB (root, home etc)
> /boot : ext3 : 1GB
> /tmp : ext2 : 2GB
> /usr : ext3 : 4GB
> /var : ext3 : 6GB
> -----------------------
> 60GB
>
> VG : 190GB approx
> -----------------------
> Initially divided so:
> /data : ext3 : 90GB
> /postgres : xfs : 40GB
>
> This gives me left over space of roughly 60GB to extend into on the
> volume group, which I can balance between the /data and /postgres
> logical volumes as needed.
>
> Are there any major pitfalls to this approach?
>
> Thanks,
> Rory
>
It looks like you are using fast disks and xfs for filesystem on the
/postgresql partition. That's nice.
How many disks in the array?
One thing you miss is sticking a bunch of sequential log writes on a
separate spindle as far as I can see with this? WAL / XFS (i think) both
have this pattern. If you've got a fast disk and can do BBU write
caching your WAL writes will hustle.
Others can probably speak a bit better on any potential speedups.
- August
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: LVM and Postgres
@ 2005-12-06 21:36 Rory Campbell-Lange <rory@campbell-lange.net>
parent: August Zajonc <augustz@augustz.com>
0 siblings, 1 reply; 8+ messages in thread
From: Rory Campbell-Lange @ 2005-12-06 21:36 UTC (permalink / raw)
To: August Zajonc <augustz@augustz.com>; +Cc: pgsql-performance
Hi August. Thanks very much for your mail.
On 06/12/05, August Zajonc (augustz@augustz.com) wrote:
> Rory Campbell-Lange wrote:
> >The server has a 250GB RAID10 (LSI 320-I + BBU) volume which I am
> >thinking of slicing up in the following way (Linux 2.6 kernel):
> >
> > / : ext3 : 47GB (root, home etc)
> > /boot : ext3 : 1GB
> > /tmp : ext2 : 2GB
> > /usr : ext3 : 4GB
> > /var : ext3 : 6GB
> > -----------------------
> > 60GB
> >
> > VG : 190GB approx
> > -----------------------
> > Initially divided so:
> > /data : ext3 : 90GB
> > /postgres : xfs : 40GB
> >
> >This gives me left over space of roughly 60GB to extend into on the
> >volume group, which I can balance between the /data and /postgres
> >logical volumes as needed.
>
> It looks like you are using fast disks and xfs for filesystem on the
> /postgresql partition. That's nice.
>
> How many disks in the array?
Four.
> One thing you miss is sticking a bunch of sequential log writes on a
> separate spindle as far as I can see with this? WAL / XFS (i think) both
> have this pattern. If you've got a fast disk and can do BBU write
> caching your WAL writes will hustle.
Yes, we don't have any spare disks unfortunately. We have enabled the
BBU write, so we are hoping for good performance. I'd be grateful for
some advice on dd/bonnie++ tests for checking this.
> Others can probably speak a bit better on any potential speedups.
I'd better test extending the Logical Volumes too!
Many thanks
Rory
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: LVM and Postgres
@ 2005-12-07 00:25 Michael Stone <mstone+postgres@mathom.us>
parent: Rory Campbell-Lange <rory@campbell-lange.net>
0 siblings, 1 reply; 8+ messages in thread
From: Michael Stone @ 2005-12-07 00:25 UTC (permalink / raw)
To: pgsql-performance
On Tue, Dec 06, 2005 at 09:36:23PM +0000, Rory Campbell-Lange wrote:
>Yes, we don't have any spare disks unfortunately. We have enabled the
>BBU write, so we are hoping for good performance.
Even if you don't use seperate disks you'll probably get better
performance by putting the WAL on a seperate ext2 partition. xfs gives
good performance for the table data, but is not particularly good for
the WAL.
Mike Stone
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: LVM and Postgres
@ 2005-12-07 00:52 Alex Turner <armtuk@gmail.com>
parent: Michael Stone <mstone+postgres@mathom.us>
0 siblings, 1 reply; 8+ messages in thread
From: Alex Turner @ 2005-12-07 00:52 UTC (permalink / raw)
To: pgsql-performance
I would argue that almost certainly won't by doing that as you will
create a new place even further away for the disk head to seek to
instead of just another file on the same FS that is probably closer to
the current head position.
Alex
On 12/6/05, Michael Stone <mstone+postgres@mathom.us> wrote:
> On Tue, Dec 06, 2005 at 09:36:23PM +0000, Rory Campbell-Lange wrote:
> >Yes, we don't have any spare disks unfortunately. We have enabled the
> >BBU write, so we are hoping for good performance.
>
> Even if you don't use seperate disks you'll probably get better
> performance by putting the WAL on a seperate ext2 partition. xfs gives
> good performance for the table data, but is not particularly good for
> the WAL.
>
> Mike Stone
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: LVM and Postgres
@ 2005-12-07 01:31 Michael Stone <mstone+postgres@mathom.us>
parent: Alex Turner <armtuk@gmail.com>
0 siblings, 2 replies; 8+ messages in thread
From: Michael Stone @ 2005-12-07 01:31 UTC (permalink / raw)
To: Alex Turner <armtuk@gmail.com>; +Cc: pgsql-performance
On Tue, Dec 06, 2005 at 07:52:25PM -0500, Alex Turner wrote:
>I would argue that almost certainly won't by doing that as you will
>create a new place even further away for the disk head to seek to
>instead of just another file on the same FS that is probably closer to
>the current head position.
I would argue that you should benchmark it instead of speculating. You
are perhaps underestimating the effect of the xfs log. (Ordinarily xfs
has great performance, but it seems to be fairly lousy at
fsync/osync/etc operations in my benchmarks; my wild speculation is that
the sync forces a log flush.) At any rate you're going to have a lot of
head movement on any reasonably sized filesystem anyway, and I'm not
convinced that hoping that your data will happen to land close to your log is
a valid, repeatable optimization technique. Note that the WAL will
wander around the disk as files are created and deleted, whereas tables
are basically updated in place.
Mike Stone
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: LVM and Postgres
@ 2005-12-07 04:14 Kevin Brown <kevin@sysexperts.com>
parent: Michael Stone <mstone+postgres@mathom.us>
1 sibling, 0 replies; 8+ messages in thread
From: Kevin Brown @ 2005-12-07 04:14 UTC (permalink / raw)
To: pgsql-performance; +Cc: Alex Turner <armtuk@gmail.com>
Michael Stone wrote:
> Note that the WAL will
> wander around the disk as files are created and deleted, whereas tables
> are basically updated in place.
Huh? I was rather under the impression that the WAL files (in
pg_xlog, right?) were reused once they'd been created, so their
locations on the disk should remain the same, as should their data
blocks (roughly, depending on the implementation of the filesystem, of
course).
--
Kevin Brown kevin@sysexperts.com
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: LVM and Postgres
@ 2005-12-08 11:28 Rory Campbell-Lange <rory@campbell-lange.net>
parent: Michael Stone <mstone+postgres@mathom.us>
1 sibling, 0 replies; 8+ messages in thread
From: Rory Campbell-Lange @ 2005-12-08 11:28 UTC (permalink / raw)
To: Alex Turner <armtuk@gmail.com>; pgsql-performance
On 06/12/05, Michael Stone (mstone+postgres@mathom.us) wrote:
> On Tue, Dec 06, 2005 at 07:52:25PM -0500, Alex Turner wrote:
> >I would argue that almost certainly won't by doing that as you will
> >create a new place even further away for the disk head to seek to
> >instead of just another file on the same FS that is probably closer to
> >the current head position.
>
> I would argue that you should benchmark it instead of speculating.
Is there a good way of benchmarking? We don't have much in the way of
test data at present.
Regards,
Rory
--
Rory Campbell-Lange
<rory@campbell-lange.net>
<www.campbell-lange.net>
^ permalink raw reply [nested|flat] 8+ messages in thread
end of thread, other threads:[~2005-12-08 11:28 UTC | newest]
Thread overview: 8+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2005-12-06 09:38 LVM and Postgres Rory Campbell-Lange <rory@campbell-lange.net>
2005-12-06 20:12 ` August Zajonc <augustz@augustz.com>
2005-12-06 21:36 ` Rory Campbell-Lange <rory@campbell-lange.net>
2005-12-07 00:25 ` Michael Stone <mstone+postgres@mathom.us>
2005-12-07 00:52 ` Alex Turner <armtuk@gmail.com>
2005-12-07 01:31 ` Michael Stone <mstone+postgres@mathom.us>
2005-12-07 04:14 ` Kevin Brown <kevin@sysexperts.com>
2005-12-08 11:28 ` Rory Campbell-Lange <rory@campbell-lange.net>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox