From: | "Tomas Vondra" <tv(at)fuzzy(dot)cz> |
---|---|
To: | "Ogden" <lists(at)darkstatic(dot)com> |
Cc: | "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>, "Tomas Vondra" <tv(at)fuzzy(dot)cz>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Tuning Tips for a new Server |
Date: | 2011-08-17 19:44:10 |
Message-ID: | 25ef8274681f922758ff3462b30d9be0.squirrel@sq.gransy.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 17 Srpen 2011, 21:22, Ogden wrote:
>> This is a very important point. I've found on most machines with
>> hardware caching RAID and 8 or fewer 15k SCSI drives it's just as
>> fast to put it all on one big RAID-10 and if necessary partition it to
>> put the pg_xlog on its own file system. After that depending on the
>> workload you might need a LOT of drives in the pg_xlog dir or just a
>> pair. Under normal ops many dbs will use only a tiny % of a
>> dedicated pg_xlog. Then something like a site indexer starts to run,
>> and writing heavily to the db, and the usage shoots to 100% and it's
>> the bottleneck.
>
> I suppose this is my confusion. Or rather I am curious about this. On my
> current production database the pg_xlog directory is 8Gb (our total
> database is 200Gb). Does this warrant a totally separate setup (and
> hardware) than PGDATA?
This is not about database size, it's about the workload - the way you're
using your database. Even a small database may produce a lot of WAL
segments, if the workload is write-heavy. So it's impossible to recommend
something except to try that on your own.
Tomas
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-08-17 20:12:25 | Re: DBT-5 & Postgres 9.0.3 |
Previous Message | Ogden | 2011-08-17 19:22:24 | Re: Tuning Tips for a new Server |