Re: Reports from SSD purgatory
От | david@lang.hm |
---|---|
Тема | Re: Reports from SSD purgatory |
Дата | |
Msg-id | alpine.DEB.2.02.1108241207240.5855@asgard.lang.hm обсуждение исходный текст |
Ответ на | Re: Reports from SSD purgatory (Merlin Moncure <mmoncure@gmail.com>) |
Список | pgsql-performance |
On Wed, 24 Aug 2011, Merlin Moncure wrote: > On Wed, Aug 24, 2011 at 1:48 PM, <gnuoytr@rcn.com> wrote: >> >> >> >> Also, given that PG is *nix centric and support for TRIM is win >> centric, having that makes a big difference in performance. > > one point about TRIM -- no raid controller that I know of supports > trim, which suggests it might not even be possible to support. How > much does it help really? Probably not as much as you would think > because newer SSD drives have very sophisticated controllers that make > it at least partially obsolete. if the SSD can know that the user doesn't care about data in a particular block, the SSD can overwrite that block with new data. Since the SSDs do their writing to new blocks and erase old blocks later, the more empty blocks you have available, the less likely you are to hit a garbage collection pause when you try to write to the drive. if you are careful to never write temporary files to the drive and only use it for database-like 'update in place' type of things (no 'write a new file and then rename it over the old one' tricks), then TRIM won't make any difference because every block that you have ever written to is one that you care about (or close enough to this for practical purposes) but if you don't take this care, the drive works to preserve all the data blocks that you have ever written to, even if the filesystem has freed them and dosn't care about them. The worst case would be a log strcutured filesystem (btrfs for example) where every write is to a new block and then the old block is freed later. David Lang
В списке pgsql-performance по дате отправления: