Re: New server: SSD/RAID recommendations?

On 7/7/2015 05:56, Mkrtchyan, Tigran wrote:

----- Original Message -----

From: "Graeme B. Bell" <graeme.bell@nibio.no>
To: "Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de>
Cc: "Graeme B. Bell" <graeme.bell@nibio.no>, "Steve Crawford" <scrawford@pinpointresearch.com>, "Wes Vaske (wvaske)"
<wvaske@micron.com>, "pgsql-performance" <pgsql-performance@postgresql.org>
Sent: Tuesday, July 7, 2015 12:38:10 PM
Subject: Re: [PERFORM] New server: SSD/RAID recommendations?

I am unsure about the performance side but, ZFS is generally very attractive to
me.

Key advantages:

1) Checksumming and automatic fixing-of-broken-things on every file (not just
postgres pages, but your scripts, O/S, program files).
2) Built-in  lightweight compression (doesn't help with TOAST tables, in fact
may slow them down, but helpful for other things). This may actually be a net
negative for pg so maybe turn it off.
3) ZRAID mirroring or ZRAID5/6. If you have trouble persuading someone that it's
safe to replace a RAID array with a single drive... you can use a couple of
NVMe SSDs with ZFS mirror or zraid, and  get the same availability you'd get
from a RAID controller. Slightly better, arguably, since they claim to have
fixed the raid write-hole problem.
4) filesystem snapshotting

Despite the costs of checksumming etc., I suspect ZRAID running on a fast CPU
with multiple NVMe drives will outperform quite a lot of the alternatives, with
great data integrity guarantees.

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.