Re: Linux v.s. Mac OS-X Performance

>> Anyway, how does MacOS X (both 10.4 and 10.5) compare to Windows
>> (2000, XP, Vista etc.) on the same hardware? And Linux to
>> (Free-/Net-/whatever) BSD?
>
> Apple hardware gets so expensive for some types of database
> configurations that such a comparision doesn't even make a lot of
> sense.

So far my experience with the effective price/performance ratio of
Apple vs. other Hardware for my applications has been pretty good. E.g.
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.

Not to mention the required learning effort for Linux/*BSD compared to
MacOS X, if I count it in (days x day rate)...

> 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...?

> If I have a PC,
> the entry-level solution in that category can be a random sub-$1000
> system that runs Linux

Can't find one over here for that price that does all the other things
that need to be done in a typicle small office (fileserver,
printserver, mailserver, calendar server,...) similarly well as my old
G5 PowerMac. To turn this one into a part-time DB server, I'd just plug
in an eSATA or SAS array (with PCIe adapter) and maybe another few GB
of RAM (currently 4). Plus a backup tape drive.

My world are environments with not more than at most 10 concurrent
database clients at any given moment. But those won't want to wait,
because they need to get actual work done.

> plus around $400 for a RAID card with BBC, and
> you've got multiple vendors to consider there (3Ware, Areca, LSI
> Logic, etc.)

LSI drivers are not available for MacOS X on PowerMacs? Ouch.

> Also, in previous generations, the Mach kernel core of Mac OS had
> some serious performance issues for database use even in read-heavy
> workloads: http://www.anandtech.com/mac/showdoc.aspx?i=2520&p=5

"With the MySQL performance woes now clearly caused by OS X"

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.

I wouldn't use MySQL anyway, and I'm mostly interested in transaction
performance (client waiting time until commit).

>> I'm just wondering whether the performance gain is worth the
>> learning effort required for Linux or BSD compared to the Mac.
>
> On both Windows (where you get limitations like not being able to set
> a large value for shared_buffers)

My consistent experience with Windows over the last >15 years has been
that it just won't multitask anymore as soon as one process does
significant I/O. No matter what hardware you put underneath.

> and Mac OS X, PostgreSQL has enough
> performance issues that I feel using those plaforms can only be
> justified if platform compatibility is more important than
> performance to you.

The point is that cost for "installation", "configuration" and
"administration" must be taken into account. A dedicated individual
just for that is simply out of question in this world where I live. So
someone who's already available has to do all that in a (as tiny as
possible) fraction of his/her worktime. With MacOS X it's feasible, but
Linux/*BSD? I'm not so sure.

Sincerely,

Wolfgang Keller

On 30.11.2007, at 04:48, Wolfgang Keller wrote:

> LSI drivers are not available for MacOS X on PowerMacs? Ouch.

The problem is that they suck as they can't to channel bundling for
higher trough-put to a single disk array.

[not your comment, but referred there]
>> and Mac OS X, PostgreSQL has enough
>> performance issues that I feel using those plaforms can only be
>> justified if platform compatibility is more important than
>> performance to you.

Actually - In our test if just used with a similar load as pgbench
(e.g. typical web applications) Mac OS X 10.4.7 performed better then
Yellow Dog Linux (I was testing with G5 hardware) on the same hardware
as soon as more than about 90 concurrent clients were simulated.

But okay, don't trust statistics you didn't make up yourself ...

cug

On Fri, 30 Nov 2007, Guido Neitzer wrote:

> Actually - In our test if just used with a similar load as pgbench (e.g.
> typical web applications) Mac OS X 10.4.7 performed better then Yellow Dog
> Linux (I was testing with G5 hardware) on the same hardware as soon as more
> than about 90 concurrent clients were simulated.

At this point, that's just an interesting historical note. Yellow Dog is
not a particularly good Linux compared with the ones that have gotten
years worth of performance tuning for Intel/AMD processors. And you
really can't extrapolate anything useful today from how it ran on a
G5--that's two layers of obsolete. The comparisons that matter now are
Intel+Mac OS vs. Intel+a popular Linux aimed at servers.

As an unrelated note, I'm curious what you did with pgbench that you
consider it a reasonable similation of a web application. The default
pgbench transaction is very write-heavy, and the read-only option
available is way too simple to be realistic. You'd need to pass in custom
scripts to execute to get something that acted like a web app. pgbench is
an unruly tool, and there's many ways to run it that gives results that
aren't so useful.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

At 6:15 PM -0500 11/30/07, Greg Smith wrote:
>On Fri, 30 Nov 2007, Guido Neitzer wrote:
>
>>Actually - In our test if just used with a similar load as pgbench
>>(e.g. typical web applications) Mac OS X 10.4.7 performed better
>>then Yellow Dog Linux (I was testing with G5 hardware) on the same
>>hardware as soon as more than about 90 concurrent clients were
>>simulated.
>
>At this point, that's just an interesting historical note. Yellow
>Dog is not a particularly good Linux compared with the ones that
>have gotten years worth of performance tuning for Intel/AMD
>processors. And you really can't extrapolate anything useful today
>from how it ran on a G5--that's two layers of obsolete. The
>comparisons that matter now are Intel+Mac OS vs. Intel+a popular
>Linux aimed at servers.
>
>As an unrelated note, I'm curious what you did with pgbench that you
>consider it a reasonable similation of a web application. The
>default pgbench transaction is very write-heavy, and the read-only
>option available is way too simple to be realistic. You'd need to
>pass in custom scripts to execute to get something that acted like a
>web app. pgbench is an unruly tool, and there's many ways to run it
>that gives results that aren't so useful.

If this is any help to anyone, I'm running Postgresql on an Intel
Xserve Mac OS X. Performance is more than fine for my usage. If
anyone would like me to run some benchmark code to test comparisons,
I'd be happy to do so.

-Owen

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(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD