Thread: LVM and Postgres
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>
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
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
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
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 >
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
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
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>