From: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Steven Schlansker <steven(at)likeness(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Deploying PostgreSQL on CentOS with SSD and Hardware RAID |
Date: | 2013-05-11 14:27:30 |
Message-ID: | 518E5552.9030909@commandprompt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 05/10/2013 11:38 AM, Merlin Moncure wrote:
>> PostgreSQL configuration changes:
>> synchronous_commit = off
>> effective_io_concurrency = 4
>> checkpoint_segments = 1024
>> checkpoint_timeout = 10min
>> checkpoint_warning = 8min
>> shared_buffers = 32gb
>> temp_buffers = 128mb
>> work_mem = 512mb
>> maintenance_work_mem = 1gb
>
> that's good info, but it should be noted that synchronous_commit
> trades a risk of some data loss (but not nearly as much risk as
> volatile storage) for a big increase in commit performance.
Yeah but it is an extremely low risk, and probably lower than say... a
bad Apache form submission. Generally the database is the most reliable
hardware in the cluster. It is also not a risk for corruption which a
lot of people confuse it for.
One thing I would note is that work_mem is very high, that might be
alright with an SSD environment because if we go out to tape sort, it is
still going to be fast but it is something to consider.
Another thing is, why such a low checkpoint_timout? Set it to 60 minutes
and be done with it. The bgwriter should be dealing with these problems.
Sincerely,
JD
>
> merlin
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Moshe Jacobson | 2013-05-11 14:56:17 | How to clone a running master cluster? |
Previous Message | Matt Brock | 2013-05-11 09:10:41 | Re: Deploying PostgreSQL on CentOS with SSD and Hardware RAID |