On Fri, 30 Nov 2007, Wolfgang Keller wrote:
it was impossible for me to find a similarly priced
(Linux-/*BSD/Intel/AMD-)equivalent to my PowerMac G5 over here at the
time when I bought it.
The problem from my perspective is the common complaint that Apple doesn't
ship an inexpensive desktop product that would be suitable for light-duty
server work. Their cheapest system you can add a PCI-X card to is $2200
USD (I just priced a system out and realized I can downgrade the
processors from the default), and that has only has 4 SATA drive bays
which doesn't make it much of a serious database server platform. A
similarly configured system from Dell runs around $1900, which gives the
usual (and completely reasonable) Apple tax of around $300. However, I
can just as easily pop over to Dell, buy a $500 system, drop an SATA
RAID+BBC controller in for another $400, and I've got a perfectly
reasonable little server--one that on write-heavy loads will outperform at
least double its price in Apple hardware, simply because that's how much
it costs to get the cheapest system you can put a caching controller in
from them.
(Don't anyone take that as a recommendation for Dell hardware, which I
hate, but simply as a reference point; the only thing I like about them is
that the system building interface on their web site makes it easy to do
comparisons like this)
For example, if you have an application that needs high
database write throughput, to make that work well with PostgreSQL you
must have a controller with a battery backed cache.
Hmm, what would be the difference compared to plenty of RAM and a UPS (plus
stand-by backup server)? Looks just like moving the "single point of failure"
to adifferent hardware item, no...?
When you write a WAL record to commit a transaction, if you can cache that
write it doesn't slow any client down. If you can't, the database waits
for a physical write to the disk, which can only happen at a rate that
depends on your disk's rotation speed. For a standard 7200RPM drive, that
tops out a bit less than 120 writes/second for any single client, and
somewhere around 500 total for larger numbers of simultaneous clients.
The only robust way to cache a write involves a battery-backed controller.
Relying on RAM or the write cache in the drives, even if you have the
world's greatest UPS, means that the first person who accidentally unplugs
your system (or the first power supply failure) could corrupt your
database. That's really not acceptable for anyone. But since the
integrity policy of the good caching controlers is far better than that,
you can leave that cache on safely, and only expect corruption if there's
a multi-day power outage.
It's still more rambling than I'd like, but I have the pieces to a full
discussion of this topic at
http://www.westnet.com/~gsmith/content/postgresql/TuningPGWAL.htm
LSI drivers are not available for MacOS X on PowerMacs? Ouch.
There might be something out there, but I'm not aware of anything from
them or other vendors targeted at the current Intel Power Macs that looks
robust; there's just Apple's offering.
Erm, systematic error here: It could also be that the MySQL
implementation/configuration for the two different OSes was the source
for the performance difference.
That's possible, but other than the specific fsync write fixes they
applied for OS X I'm not aware of anything specific to Mac OS that would
cause this. When the low-level benchmarks show awful performance doing
things like creating processes, and performance dives under a heavy load,
it seems sensible to assume the two are linked until proven otherwise.
(Appropriate disclaimer:
http://en.wikipedia.org/wiki/Correlation_does_not_imply_causation )
It's also true that some of the MySQL threading limitations that were
brought up in a tangent to this discussion could be contributing as well,
in which case a PostgreSQL test might not show as large of a gap. Again,
criticizing the benchmark methods doesn't accomplish anything, you need an
advocate for the platform to perform ones showing otherwise before the
current results are disproven.
The point is that cost for "installation", "configuration" and
"administration" must be taken into account.
The question you asked about was how Apple Hardware+Mac OS X+PostgreSQL
stacks up on a performance basis with more common platforms like PC
hardware+Linux. All the answers I've seen suggest not very well, and none
of these other things are relevant when evaluating the platform from a
performance perspetive. TCO issues are all relative to the administrator
and tasks anyway--an experienced Linux system administrator may be a
little slower on some things than one running Apple's GUI tools, but once
you get to more scriptable changes they could be far more efficient.
--
* Greg Smith gsmith@xxxxxxxxxxxxx http://www.gregsmith.com Baltimore, MD
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
