Re: rough benchmarks, sata vs. ssd

Поиск
Список
Период
Сортировка
От Ivan Voras
Тема Re: rough benchmarks, sata vs. ssd
Дата
Msg-id jggg2s$dse$1@dough.gmane.org
обсуждение исходный текст
Ответ на rough benchmarks, sata vs. ssd  (CSS <css@morefoo.com>)
Ответы Re: rough benchmarks, sata vs. ssd
Список pgsql-performance
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.

В списке pgsql-performance по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: *really* bad insert performance on table with unique index
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Slow nested loop execution on larger server