From owner-freebsd-fs@FreeBSD.ORG Thu Oct 24 17:27:06 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C97BBBC7 for ; Thu, 24 Oct 2013 17:27:06 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 945102D70 for ; Thu, 24 Oct 2013 17:27:06 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id uy5so2635446obc.38 for ; Thu, 24 Oct 2013 10:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=iZoKHeuMbT4J3Bml5xFLRB8hTI1SgBCi+g1V4se5rO8=; b=Bkw6thqLJGOjAa3IVMXK9ikiiytee59BCAjaSzZ2vr2hygHeRJyKhQrnxGRiT3IXRj Ytoj9N/AIYy/+IQCD6LBh/BhKD6jgrb+fzh4kZjj712y7xjOhganIyBspDebVh5wcK4G SHZzPVMUhw8own1QjqmrGImsM+4oMsJnVBM7OeeaibdreDQn0seTEfIIlwsxq1T1Imum HgMtSpO9k1QSmJEl3WSzPUFE/ELyj1B7IIWYjkFVeN2PulEIyAgkA4zxu2V47vpe0xqz QjYYmMuw4k4Z/g1RPXQ6q98YcQQ4Y2bwnJtA085syFA5arDfcXg7ZRYHAfJ6Ml4w27sL TivQ== MIME-Version: 1.0 X-Received: by 10.60.63.36 with SMTP id d4mr2983743oes.29.1382635625254; Thu, 24 Oct 2013 10:27:05 -0700 (PDT) Received: by 10.76.132.9 with HTTP; Thu, 24 Oct 2013 10:27:05 -0700 (PDT) In-Reply-To: <52691558.5060306@digsys.bg> References: <20131023162545.GA19794@pcjas.obspm.fr> <52691558.5060306@digsys.bg> Date: Thu, 24 Oct 2013 10:27:05 -0700 Message-ID: Subject: Re: ZFS-FreeBSD + postgresql performance From: Freddie Cash To: FreeBSD Filesystems Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 17:27:06 -0000 On Thu, Oct 24, 2013 at 5:40 AM, Daniel Kalchev wrote: > > On 24.10.13 15:25, krad wrote: > >> If your dbs are doing lots of writes, consider implementing raid 10 on t= he >> > pools level as its much faster for writes. >> > > By all means, if you will run PostgreSQL on the zpool avoid any other > redundancy than MIRROR. You will be better having one separate MIRROR (or > multiple mirror vdevs) pool for the DB and another for other data, any ti= me. > > As you have a lots of dbs, and potentially a lot of spindles, you could >> mix >> =E2=80=8B a=E2=80=8B >> nd match the above ideas depending on the dbs profile. Have say a raidz6 >> =E2=80=8B =E2=80=8B >> pool for you lower traffic mostly read dbs, a raid 10 pool for your heav= y >> =E2=80=8B =E2=80=8B >> write dbs, and a dedicated pool for you low latency db >> > > I have actually experimented with this, in using 15k drives for the "fast= " > databases and 10k drives for the "slow" databases. At the end, I discover= ed > it was better idea to combine all the drives in a single zpool with > multiple vdevs, than to do such separation -- as multiple vdevs are alway= s > going to provide you with more performance. > =E2=80=8BThere was a discussion recently on the zfs-discuss mailing list co= vering this. There were no hard numbers thrown around, but the general consensus is that a single large pool per system, comprised of many vdevs, will almost always give better performance than a system with multiple separate pools. There are, of course, exceptions, but in general, you want to limit the number of individual pools per system. For example, a pool for the OS running on some small HDs; a pool of mirror vdevs using fast disk for things needed a lot of performance; and a pool of large/slow disks in raidz2/3 for things that need a lot of storage. =E2=80=8B =E2=80=8BOr, just go with a lot of raidz2/3 vdevs with a bunch of L2ARC in = front of it. Performance might be good enough for your needs. Or, just go with a lot of mirror vdevs if you need the raw throughput (maybe 3-way mirrors if you're paranoid). --=20 Freddie Cash fjwcash@gmail.com