DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	b=AeCculIzWykWWQTDcbsxoi2bzVDn10m5K5GdoeR8cGUIfJkkf5LYHhCSGGWIiLpUWk
	OQhIt6p3IjwuZcSIwkBFGys0zngpk9n2G4mXWjYyA4rv5CDS7QvtXUwyL4zMZkghOn+q
	13fmjZds4F4vgwXJsxa/hxIJHOtPASnXA5RKc=
MIME-Version: 1.0
In-Reply-To: <4BE4ABC9.6040106@agliodbs.com>
References: <4BE4ABC9.6040106@agliodbs.com>
Date: Sun, 9 May 2010 10:45:18 +0200
Message-ID: <AANLkTim6rVYoAZaspbEnsyE9LPmWGXWe4Van40Snldoj@mail.gmail.com>
Subject: Re: 8K recordsize bad on ZFS?
From: Dimitri <dimitrik.fr@gmail.com>
To: Josh Berkus <josh@agliodbs.com>
Cc: pgsql-performance@postgresql.org, Jignesh Shah <jkshah@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Josh,

it'll be great if you explain how did you change the records size to
128K? - as this size is assigned on the file creation and cannot be
changed later - I suppose that you made a backup of your data and then
process a full restore.. is it so?

Rgds,
-Dimitri


On 5/8/10, Josh Berkus <josh@agliodbs.com> wrote:
> Jignesh, All:
>
> Most of our Solaris users have been, I think, following Jignesh's advice
> from his benchmark tests to set ZFS page size to 8K for the data zpool.
>  However, I've discovered that this is sometimes a serious problem for
> some hardware.
>
> For example, having the recordsize set to 8K on a Sun 4170 with 8 drives
> recently gave me these appalling Bonnie++ results:
>
> Version  1.96       ------Sequential Output------ --Sequential Input-
> --Random-
> Concurrency   4     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
> --Seeks--
> Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP
> /sec %CP
> db111           24G           260044  33 62110  17           89914  15
> 1167  25
> Latency                        6549ms    4882ms              3395ms
> 107ms
>
> I know that's hard to read.  What it's saying is:
>
> Seq Writes: 260mb/s combined
> Seq Reads: 89mb/s combined
> Read Latency: 3.3s
>
> Best guess is that this is a result of overloading the array/drives with
> commands for all those small blocks; certainly the behavior observed
> (stuttering I/O, latency) is in line with that issue.
>
> Anyway, since this is a DW-like workload, we just bumped the recordsize
> up to 128K and the performance issues went away ... reads up over 300mb/s.
>
> --
>                                   -- Josh Berkus
>                                      PostgreSQL Experts Inc.
>                                      http://www.pgexperts.com
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>