Re: New server: SSD/RAID recommendations?

From: "Graeme B(dot) Bell" <graeme(dot)bell(at)nibio(dot)no>
To: Karl Denninger <karl(at)denninger(dot)net>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: New server: SSD/RAID recommendations?
Date: 2015-07-07 11:52:07
Message-ID: B9C4FEE4-1527-4CB0-B941-CF6F2CF38D4E@skogoglandskap.no
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 performance on ssds :-)

128kb blocks + compression certainly makes sense. But it might make less sense I suppose if you had some incredibly high rate 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(at)denninger(dot)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 improvement in throughput using compression and the larger blocksize, which is counter-intuitive and also opposite the "conventional wisdom."
>
> For best throughput we use mirrored vdev sets.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Graeme B. Bell 2015-07-07 12:04:21 Re: New server: SSD/RAID recommendations?
Previous Message eudald_v 2015-07-07 11:29:23 Re: Sudden connection and load average spikes with postgresql 9.3