From: | David Boreham <david_list(at)boreham(dot)org> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Deploying PostgreSQL on CentOS with SSD and Hardware RAID |
Date: | 2013-05-20 05:12:09 |
Message-ID: | 5199B0A9.7010908@boreham.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 5/19/2013 7:19 PM, Toby Corkindale wrote:
> On 13/05/13 11:23, David Boreham wrote:
>> btw we deploy on CentOS6. The only things we change from the default
>> are:
>>
>> 1. add "relatime,discard" options to the mount (check whether the most
>> recent CentOS6 does this itself -- it didn't back when we first deployed
>> on 6.0).
>
>
> While it is important to let the SSD know about space that can be
> reclaimed, I gather the operation does not perform well.
> I *think* current advice is to leave 'discard' off the mount options,
> and instead run a nightly cron job to call 'fstrim' on the mount point
> instead. (In really high write situations, you'd be looking at calling
> that every hour instead I suppose)
>
> I have to admit to have just gone with the advice, rather than
> benchmarking it thoroughly.
The guy who blogged about this a couple of years ago was using a
Sandforce controller drive.
I'm not sure there is a similar issue with other drives. Certainly we've
never noticed a problematic delay in file deletes.
That said, our applications don't delete files too often (log file
purging is probably the only place it happens regularly).
Personally, in the absence of a clear and present issue, I'd prefer to
go the "kernel guys and drive firmware guys will take care of this"
route, and just enable discard on the mount.
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Amiel | 2013-05-20 14:01:27 | Re: Why does row estimation on nested loop make no sense to me |
Previous Message | Tom Lane | 2013-05-20 01:36:53 | Re: C function fails afeter create extension but ok after reconnect |