From: Laszlo Nagy <gandalf@shopzeus.com>
To: Greg Smith <greg@2ndQuadrant.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: ZFS vs. UFS
Date: Tue, 31 Jul 2012 10:50:11 +0200
Message-ID: <50179C43.5030607@shopzeus.com> (raw)
In-Reply-To: <5012261A.8040007@2ndQuadrant.com>
References: <500E9A3B.3070609@shopzeus.com>
<5012261A.8040007@2ndQuadrant.com>
> When Intel RAID controller is that? All of the ones on the
> motherboard are pretty much useless if that's what you have. Those are
> slower than software RAID and it's going to add driver issues you
> could otherwise avoid. Better to connect the drives to the non-RAID
> ports or configure the controller in JBOD mode first.
>
> Using one of the better RAID controllers, one of Dell's good PERC
> models for example, is one of the biggest hardware upgrades you could
> make to this server. If your database is mostly read traffic, it
> won't matter very much. Write-heavy loads really benefit from a good
> RAID controller's write cache.
Actually, it is a PERC with write-cache and BBU.
>
> ZFS will heavily use server RAM for caching by default, much more so
> than UFS. Make sure you check into that, and leave enough RAM for the
> database to run too. (Doing *some* caching that way is good for
> Postgres; you just don't want *all* the memory to be used for that)
Right now, the size of the database is below 5GB. So I guess it will fit
into memory. I'm concerned about data safety and availability. I have
been in a situation where the RAID card went wrong and I was not able to
recover the data because I could not get an identical RAID card in time.
I have also been in a situation where the system was crashing two times
a day, and we didn't know why. (As it turned out, it was a bug in the
"stable" kernel and we could not identify this for two weeks.) However,
we had to do fsck after every crash. With a 10TB disk array, it was
extremely painful. ZFS is much better: short recovery time and it is
RAID card independent. So I think I have answered my own question - I'm
going to use ZFS to have better availability, even if it leads to poor
performance. (That was the original question: how bad it it to use ZFS
for PostgreSQL, instead of the native UFS.)
>
> Moving disks to another server is a very low probability fix for a
> broken system. The disks are a likely place for the actual failure to
> happen at in the first place.
Yes, but we don't have to worry about that. raidz2 + hot spare is safe
enough. The RAID card is the only single point of failure.
> I like to think more in terms of "how can I create a real-time replica
> of this data?" to protect databases, and the standby server for that
> doesn't need to be an expensive system. That said, there is no reason
> to set things up so that they only work with that Intel RAID
> controller, given that it's not a very good piece of hardware anyway.
I'm not sure how to create a real-time replica. This database is updated
frequently. There is always a process that reads/writes into the
database. I was thinking about using slony to create slave databases. I
have no experience with that. We have a 100Mbit connection. I'm not sure
how much bandwidth we need to maintain a real-time slave database. It
might be a good idea.
I'm sorry, I feel I'm being off-topic.
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: gandalf@shopzeus.com, greg@2ndQuadrant.com
Subject: Re: ZFS vs. UFS
In-Reply-To: <50179C43.5030607@shopzeus.com>
* 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