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
>
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 |