Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <pgsql-admin-owner+archive@lists.postgresql.org>)
	id 1naNo4-0001hn-Gz
	for pgsql-admin@arkaria.postgresql.org; Fri, 01 Apr 2022 20:23:40 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-admin-owner+archive@lists.postgresql.org>)
	id 1naNo2-0004RA-6R
	for pgsql-admin@arkaria.postgresql.org; Fri, 01 Apr 2022 20:23:38 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <rui@crazybean.net>)
	id 1naNo1-0004R1-SE
	for pgsql-admin@lists.postgresql.org; Fri, 01 Apr 2022 20:23:37 +0000
Received: from impout009aa.msg.chrl.nc.charter.net ([47.43.20.33]
 helo=impout009.msg.chrl.nc.charter.net)
	by magus.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <rui@crazybean.net>)
	id 1naNnx-0004L8-O6
	for pgsql-admin@lists.postgresql.org; Fri, 01 Apr 2022 20:23:37 +0000
Received: from cerberus.crazybean.net ([71.11.29.254])
	by cmsmtp with ESMTP
	id aNnunEAJee8C2aNnunVefN; Fri, 01 Apr 2022 20:23:31 +0000
Authentication-Results: crazybean.net; none
X-Authority-Analysis: v=2.4 cv=HoNlpmfS c=1 sm=1 tr=0 ts=62475f43
 a=GkUsAQdcAzAk0MT19QAIRQ==:117 a=GkUsAQdcAzAk0MT19QAIRQ==:17
 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=z0gMJWrwH1QA:10 a=YfQFs2c5AAAA:8
 a=oIfrFNJ-AAAA:8 a=Go0Ewv2x4kDmJevjXOwA:9 a=QEXdDO2ut3YA:10
 a=XXry1A_VxHPudjIMQgMN:22 a=Cg2NcamS17xU0rR7el6q:22
Received: from smtpclient.apple (<unknown>
 [2001:470:e117:3:5dd9:3f8d:400:4e24])
	by cerberus.crazybean.net (OpenSMTPD) with ESMTPSA id f43e0be7
 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO);
	Fri, 1 Apr 2022 16:23:29 -0400 (EDT)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\))
Subject: Re: WAL & ZFS
From: Rui DeSousa <rui@crazybean.net>
In-Reply-To: <698D568E-058B-430D-8339-ABDA350FA742@elevated-dev.com>
Date: Fri, 1 Apr 2022 16:23:29 -0400
Cc: pgsql-admin <pgsql-admin@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E43F5F43-456E-459D-B0D5-680F599097F9@crazybean.net>
References: <FC215502-166A-49DB-B3DA-D08727A34C0B@elevated-dev.com>
 <4fe1d719-4f08-7b10-90c3-43514453757d@gmail.com>
 <41B83C10-CE63-467C-A613-FD457237A31B@crazybean.net>
 <698D568E-058B-430D-8339-ABDA350FA742@elevated-dev.com>
To: Scott Ribe <scott_ribe@elevated-dev.com>
X-Mailer: Apple Mail (2.3693.40.0.1.81)
X-CMAE-Envelope: 
 MS4xfAOzrJ1tDnlFrkj8Nw/ks7Jwy/kvgCKCxFaf3KDgRk+Cftlwr4w1MLVV/mkxDes52lIwfRqE/G0/z4sEWqGP6OqvQpYVmFOK4Hy580SKzvwTjqxWcnmR
 kpvrZNWegcDsmE5Aoze51Ai2Uajw2e6o3S3DW54sW92WzY3rCjBMx0OaIxuQH+L9rgd6Ev7BGYlT+JdRKk3gcKdVgxwJDBEmqNlkuub1V3NaRjvg8N2Ocvho
 XpveH62d9Ex6xGoHTPoc2Q==
List-Id: <pgsql-admin.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-admin@lists.postgresql.org>
List-Owner: <mailto:pgsql-admin-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-admin>
Archived-At: 
 <https://www.postgresql.org/message-id/E43F5F43-456E-459D-B0D5-680F599097F9%40crazybean.net>
Precedence: bulk



> On Apr 1, 2022, at 1:56 PM, Scott Ribe <scott_ribe@elevated-dev.com> =
wrote:
>=20
>> On Apr 1, 2022, at 11:49 AM, Rui DeSousa <rui@crazybean.net> wrote:
>>=20
>> If you=E2=80=99re using RAIDZ# then performance is going to be =
heavily impacted and I would highly recommend NOT using RAIDZ# for a =
database server.
>=20
> Actually, I found even the performance of RAIDZ1 to be acceptable =
after appropriate configuration--current versions, lz4, etc.
>=20

It might be for a low iops system; however, I would still recommend =
against it.  I haven=E2=80=99t used RAIDZ in years; it might be good for =
an archive system but I don=E2=80=99t see the value of it in a =
production database server.  You also have to account for drive failures =
and replacement time.  A replacement in a RAIDZ configuration is much =
more expense than replacing a disk in a mirrored set.  Disks today are =
larger as well and the risk of another failure during a rebuild is =
exponential increased thus the need for RAIDZ2 and RAIDZ3.

Personally and for logical reasons I would build a RAIDZ in powers of 2; =
 i.e. 2, 4, 8 drives plus parity and then have a stripe set of RAIDZ2.  =
So the first option would require 4 drives (2D + 2P) and would have same =
storage as a RAID10 configuration; however, the RAID10 would perform =
better under load.  The 4+p option seems to be the sweet spot as the =
rebuild times on larger sets are not worth it nor is it worth spreading =
out 128k over 8 drives - of course one could use a larger record size, =
but would you want to? For me 128k/16k is only 8 database blocks; =
reminds me of using Oracle=E2=80=99s readahead=3D8 option :).

Note: raidz does not alway stripe across all drives in the set like in a =
traditional raid set.  i.e. It might only use 2+p instead of 8+p as =
configured =E2=80=94 it depends on the size of the current ZFS record =
size being written out and free space.=