On 20/05/13 15:12, David Boreham wrote:
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.
This guy posted about a number of SSD drives, and enabling discard
affected most of them quite negatively:
http://people.redhat.com/lczerner/discard/ext4_discard.html
http://people.redhat.com/lczerner/discard/files/Performance_evaluation_of_Linux_DIscard_support_Dev_Con2011_Brno.pdf
That is from 2011 though, so you're right that things may have improved
by now.. Has anyone seen benchmarks supporting that though?
Toby
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
