From: Ivan Voras <ivoras@freebsd.org>
To: pgsql-performance@postgresql.org
Subject: Re: rough benchmarks, sata vs. ssd
Date: Fri, 03 Feb 2012 12:23:08 +0100
Message-ID: <jggg2s$dse$1@dough.gmane.org> (raw)
In-Reply-To: <E2B302F1-BBB3-41DD-9084-38482AC20F7C@morefoo.com>
References: <E2B302F1-BBB3-41DD-9084-38482AC20F7C@morefoo.com>
On 31/01/2012 09:07, CSS wrote:
> Hello all,
>
> Just wanted to share some results from some very basic benchmarking
> runs comparing three disk configurations on the same hardware:
>
> http://morefoo.com/bench.html
That's great!
> *Tyan B7016 mainboard w/onboard LSI SAS controller
> *2x4 core xeon E5506 (2.13GHz)
> *64GB ECC RAM (8GBx8 ECC, 1033MHz)
> *2x250GB Seagate SATA 7200.9 (ST3250824AS) drives (yes, old and slow)
> *2x160GB Intel 320 SSD drives
It shows that you can have large cheap SATA drives and small fast SSD-s,
and up to a point have best of both worlds. Could you send me
(privately) a tgz of the results (i.e. the pages+images from the above
URL), I'd like to host them somewhere more permanently.
> The ZIL is a bit of a cheat, as it allows you to throw all the
> synchronous writes to the SSD
This is one of the main reasons it was made. It's not a cheat, it's by
design.
> Why ZFS? Well, we adopted it pretty early for other tasks and it
> makes a number of tasks easy. It's been stable for us for the most
> part and our latest wave of boxes all use cheap SATA disks, which
> gives us two things - a ton of cheap space (in 1U) for snapshots and
> all the other space-consuming toys ZFS gives us, and on this cheaper
> disk type, a guarantee that we're not dealing with silent data
> corruption (these are probably the normal fanboy talking points).
> ZFS snapshots are also a big time-saver when benchmarking. For our
> own application testing I load the data once, shut down postgres,
> snapshot pgsql + the app homedir and start postgres. After each run
> that changes on-disk data, I simply rollback the snapshot.
Did you tune ZFS block size for the postgresql data directory (you'll
need to re-create the file system to do this)? When I investigated it in
the past, it really did help performance.
> I don't have any real questions for the list, but I'd love to get
> some feedback, especially on the ZIL results. The ZIL results
> interest me because I have not settled on what sort of box we'll be
> using as a replication slave for this one - I was going to either go
> the somewhat risky route of another all-SSD box or looking at just
> how cheap I can go with lots of 2.5" SAS drives in a 2U.
You probably know the answer to that: if you need lots of storage,
you'll probably be better off using large SATA drives with small SSDs
for the ZIL. 160 GB is probably more than you need for ZIL.
One thing I never tried is mirroring a SATA drive and a SSD (only makes
sense if you don't trust SSDs to be reliable yet) - I don't know if ZFS
would recognize the assymetry and direct most of the read requests to
the SSD.
> If you have any test requests that can be quickly run on the above
> hardware, let me know.
Blogbench (benchmarks/blogbench) results are always nice to see in a
comparison.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: ivoras@freebsd.org
Subject: Re: rough benchmarks, sata vs. ssd
In-Reply-To: <jggg2s$dse$1@dough.gmane.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox