Re: disk I/O problems and Solutions

From: Scott Carey <scott(at)richrelevance(dot)com>
To: David Rees <drees76(at)gmail(dot)com>, Alan McKay <alan(dot)mckay(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: disk I/O problems and Solutions
Date: 2009-10-10 02:46:10
Message-ID: C6F54382.13DE3%scott@richrelevance.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


>
>> any thoughts here?  recommendations on what to do with a tight budget?
>>  It could be the answer is that I just have to go back to the bean
>> counters and tell them we have no choice but to start spending some
>> real money.  But on what?  And how do I prove that this is the only
>> choice?
>
> It's hard to say without knowing all the information. One free
> possibility would be to move the log data onto the RAID1 from the
> RAID5, thus splitting up your database load over all of your disks.
> You can do this by moving the pg_xlog folder to the RAID1 array and
> symlink it back to your data folder. Should be able to try this with
> just a few seconds of downtime.
>

Do the above first.
Then, on your sdb, set the scheduler to 'deadline'
If it is ext3, mount sdb as 'writeback,noatime'.

If you have your pg_xlog on your RAID 5, using ext3 in 'ordered' mode, then
you are going to be continuously throwing small writes at it. If this is
the case then the above configuration changes will easily double your
performance, most likely.

> -Dave
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Scott Carey 2009-10-10 02:50:42 Re: Databases vs Schemas
Previous Message David Rees 2009-10-09 23:08:56 Re: disk I/O problems and Solutions