Skip site navigation (1) Skip section navigation (2)

Re: questions about disk configurations

From: eric soroos <eric-psql(at)soroos(dot)net>
To: scott(dot)marlowe <scott(dot)marlowe(at)ihs(dot)com>,eric soroos <eric-psql(at)soroos(dot)net>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: questions about disk configurations
Date: 2002-12-09 22:44:31
Message-ID: 88924842.1172677425@[4.42.179.151] (view raw, whole thread or download thread mbox)
Thread:
Lists: pgsql-performance

> > I've been testing some configurations for low budget performance, and I 
> > haven't been able to make this help vs. one disk. (under osx, ymmv)
> 
> I haven't found anything that helps much either, except for fast drives.


> 
> You can, however, turn on the noatime mounting option under Linux (BSD has 
> something similar) and it should help speed things up on any file system.

I don't think that's an option for osx/hfs mounts, at least mount doesn't list it. (not that mount really works on 10.1.x, but whatever)
  
> You can also try turning on the async option, but I'm not sure this is a 
> problem or not for data integrity on a transaction log file system.  
> Comments?

from man mount:

            async   All I/O to the file system should be done asynchronously.
                     This is a dangerous flag to set, and should not be used
                     unless you are prepared to recreate the file system
                     should your system crash.


I'd guess that this is about the same as fsync = off, except that it's your os lying to you instead of your database.

> 
> > I rsync'd the pg_xlog directory to another disk, then set up a symlink 
> > pointing from the data/pg_xlog to /other/disk/pg_xlog. 
> >
> > I then got tps numbers that were 2/3 of the single ide drive speed. The 
> > only explanation I can come up with is that something is seeking to the 
> > symlink, then doing the actual write on the other drive. 
> 
> rsync isn't still running is it?  you can just use the cp command while 
> the database is shut down to move the pg_xlog dir.  like so:

rsync == copy, it's just that I remember the command line switches for it. 

> pg_ctl stop
> mkdir /mnt/bigdog/pg_xlog
> chown postgres.postgres /mnt/bigdog/pg_xlog
> chmod 700 /mnt/bigdog/pg_xlog
> cd $PGDATA
> cp -Rfp pg_xlog/* /mnt/bigdog/pg_xlog/
> mv pg_xlog pg_xlog.old (I always keep stuff till I'm sure I really don't 
> need it.)
> ln -s /mnt/bigdog/pg_xlog pg_xlog
> pg_ctl start
> 

This is about what I did, except that /mnt/bigdog/pg_xlog == /Volumes/scsi1. 

Where you can do something different is mount bigdog at data/pg_xlog, instead of using the symlinks. Given the interesting state of filesystem tools under osx, I can't really do that. (at least under 10.1.5, looks like the laptop running 10.2 has a little more info. not that the laptop has room for a 3.5" 10k rpm scsi drive & pci scsi card for testing...)

eric




In response to

pgsql-performance by date

Next:From: scott.marloweDate: 2002-12-09 23:00:32
Subject: Re: questions about disk configurations
Previous:From: scott.marloweDate: 2002-12-09 22:22:11
Subject: Re: questions about disk configurations

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group