Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 17 Nov 2011 21:36:34 +0000
From:      Matthew Seaman <m.seaman@infracaninophile.co.uk>
To:        freebsd-performance@freebsd.org
Subject:   Re: ZFS Few Questions
Message-ID:  <4EC57E62.9000007@infracaninophile.co.uk>
In-Reply-To: <op.v43tx8t234t2sn@tech304>
References:  <CAKy=mtCcHavRFh16yaVH86Oh6DgePmxOhbQmmAySxWA5Zn8-yA@mail.gmail.com> <op.v43tx8t234t2sn@tech304>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig41691E48561C4FB5B2B4712F
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 17/11/2011 19:04, Mark Felder wrote:
>> Question 3:
>> Anyone Recommend for MySQL server? (Performance)
>=20
> No idea; I haven't run any SQL servers on ZFS

The sort of randomly located small IOs that RDBMSes do is the hardest
sort of IO pattern for ZFS (or any filesystem for that matter) to
manage.  ZFS has a particular problem in that its default storage unit
is a 128kB block -- and the copy-on-write semantics mean that the
filesystem layer can in principle end up doing a 128kB read, altering a
few bytes, then doing a 128kB write to get that data back on disk.

You can get pretty reasonable DB performance on ZFS, but it takes quite
a bit of tuning.

   * ZFS needs plenty of RAM.  The DB needs plenty of RAM.  Exactly
     what the balance should be is hard to predict -- dependent on
     specific workloads -- so expect to spend some time benchmarking
     and experimenting with different settings.

   * Putting the ARC (Adaptive Replacement Cache) on a separate, fast
     device will make a big difference to performance.  SSD cards are
     popular for this purpose.  (Be aware though that SSDs have a
     limited lifetime, and tend to fail suddenly and completely when
     they do wear out.  You will need multiple layers of resilience and
     very good backups...)  While SSD cards are intrinsically faster
     than individual rotating magnetic media, they are no match for a
     large disk array that can spread the IO over lots of spindles.
     But that costs a very great deal of money...

   * Reducing the ZFS block size (the recordsize property when creating
     a zfs) to match the IO size of your DB system can help a lot.  Do
     this before creating the database.

   * Separating the DB's data and transaction logging onto separate ZFS
     pools helps.

See http://www.solarisinternals.com/wiki/index.php/ZFS_for_Databases for
more details.  Just about everything on that page applies equally to
FreeBSD as it does to Solaris.

	Cheers,

	Matthew

--=20
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
JID: matthew@infracaninophile.co.uk               Kent, CT11 9PW


--------------enig41691E48561C4FB5B2B4712F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7FfmsACgkQ8Mjk52CukIwIHQCeIMrBAvwSsPKGgtdkFBB54VyM
d40AniX0/CDfvD3T1CR1/IFMOJNH9S3E
=5nYt
-----END PGP SIGNATURE-----

--------------enig41691E48561C4FB5B2B4712F--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EC57E62.9000007>