Re: New server: SSD/RAID recommendations?
От | Graeme B. Bell |
---|---|
Тема | Re: New server: SSD/RAID recommendations? |
Дата | |
Msg-id | B9C4FEE4-1527-4CB0-B941-CF6F2CF38D4E@skogoglandskap.no обсуждение исходный текст |
Ответ на | Re: New server: SSD/RAID recommendations? (Karl Denninger <karl@denninger.net>) |
Ответы |
Re: New server: SSD/RAID recommendations?
|
Список | pgsql-performance |
Hi Karl, Great post, thanks. Though I don't think it's against conventional wisdom to aggregate writes into larger blocks rather than rely on 4k performanceon ssds :-) 128kb blocks + compression certainly makes sense. But it might make less sense I suppose if you had some incredibly highrate of churn in your rows. But for the work we do here, we could use 16MB blocks for all the difference it would make. (Tip to others: don't do that.128kb block performance is already enough out the IO bus to most ssds) Do you have your WAL log on a compressed zfs fs? Graeme Bell On 07 Jul 2015, at 13:28, Karl Denninger <karl@denninger.net> wrote: > Lz4 compression and standard 128kb block size has shown to be materially faster here than using 8kb blocks and no compression,both with rotating disks and SSDs. > > This is workload dependent in my experience but in the applications we put Postgres to there is a very material improvementin throughput using compression and the larger blocksize, which is counter-intuitive and also opposite the "conventionalwisdom." > > For best throughput we use mirrored vdev sets.
В списке pgsql-performance по дате отправления: