On 7/7/2015 05:56, Mkrtchyan, Tigran 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.----- Original Message -----From: "Graeme B. Bell" <graeme.bell@xxxxxxxx> To: "Mkrtchyan, Tigran" <tigran.mkrtchyan@xxxxxxx> Cc: "Graeme B. Bell" <graeme.bell@xxxxxxxx>, "Steve Crawford" <scrawford@xxxxxxxxxxxxxxxxxxxx>, "Wes Vaske (wvaske)" <wvaske@xxxxxxxxxx>, "pgsql-performance" <pgsql-performance@xxxxxxxxxxxxxx> Sent: Tuesday, July 7, 2015 12:38:10 PM Subject: Re: 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. 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. |
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
