Re: Deploying PostgreSQL on CentOS with SSD and Hardware RAID

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.

In response to

Responses

Browse pgsql-general by date

  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