Linux v.s. Mac OS-X Performance

On Nov 9, 2007 10:55 PM, Mark Niedzielski <min@epictechnologies.com> wrote:

Our developers run on MacBook Pros w/ 2G memory and our production
hardware is dual dual-Core Opterons w/ 8G memory running CentOS 5. The
Macs perform common and complex Postgres operations in about half the
time of our unloaded production hardware. We've compared configurations
and the production hardware is running a much bigger configuration and
faster disk.

What are we missing? Is there a trick to making AMDs perform? Does
Linux suck compared to BSD?

It's quite possible that either you've got some issue with poor
hardware / OS integration (think RAID controllers that have bad
drivers, etc) or that you've de-tuned postgresql on your CentOS
machines when you thought you were tuning it. A common mistake is to
set work_mem or shared_buffers so high that they are slower than they
would be if they were smaller.

Also, if your data sets in production are hundreds of millions of
rows, and the test set on your lap top is 100,000 rows, then of course
the laptop is going to be faster, it has less data to wade through.

So, the key question is what, exactly, is different between your dev
laptops and your production machines.

On Fri, 9 Nov 2007, Mark Niedzielski wrote:

The Macs perform common and complex Postgres operations in about half
the time of our unloaded production hardware.

Are they write intensive? If so, it may be possible that the Macs are
buffering disk writes while production server isn't. It's often the case
that desktop systems will cheat at writes while servers don't.

Is there a trick to making AMDs perform?

One problem you can run into is that the default configuration on some
Linux+AMD systems will include aggressive power management that throttles
the CPU clock down. Take a look at /proc/cpuinfo on your server and see
what the "cpu MHz" reads; if it's 1000.00 or otherwise doesn't match what
you expect, you may need to turn off or otherwise tune power management to
keep the system running at full speed. My home AMD dual-core system was
positively sluggish until I fixed that.

Does Linux suck compared to BSD?

Not the Mac OS BSD. Last time I looked into this OS X was still
dramatically slower than Linux on things like process creation.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

On Fri, 9 Nov 2007, Mark Niedzielski wrote:

The Macs perform common and complex Postgres operations in about half
the time of our unloaded production hardware.

Also, what kernel are you using with CentOS 5 - a 32-bit (with hugemem
to support the 8GB) or a 64-bit? And which was PostgreSQL compiled for?

--
Steve Wampler -- swampler@noao.edu
The gods that smiled on your birth are now laughing out loud.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 09 Nov 2007 23:55:59 -0500
Mark Niedzielski <min@epictechnologies.com> wrote:

Our developers run on MacBook Pros w/ 2G memory and our production
hardware is dual dual-Core Opterons w/ 8G memory running CentOS 5.
The Macs perform common and complex Postgres operations in about half
the time of our unloaded production hardware. We've compared
configurations and the production hardware is running a much bigger
configuration and faster disk.

What are we missing?

Likely alot. Are you performing any maintenance? What are your
postgresql.conf settings? Are you running 64bit on the Linux machine?

Is there a trick to making AMDs perform? Does
Linux suck compared to BSD?

No.

Sincerely,

Joshua D. Drake

Thanks.

---------------------------(end of
broadcast)--------------------------- TIP 4: Have you searched our
list archives?

http://archives.postgresql.org/

- --

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHOIs5ATb/zqfZUUQRAo/3AJ9RLcHedTPvl1qVrOgp3Iz6jPJ4wgCfTRe+
tlLJCa1Y8Y9vZDfuxwTG/Bw=
=5hHV
-----END PGP SIGNATURE-----

On Mon, Nov 12, 2007 at 10:14:46AM -0700, Steve Wampler wrote:

Also, what kernel are you using with CentOS 5 - a 32-bit (with hugemem
to support the 8GB) or a 64-bit? And which was PostgreSQL compiled for?

You don't need a 32bit kernel to support 8GB of memory should you? As
long as the kernel supports PAE that should be enough to make use of it.
You only need a 64bit address space when each process wants to see more
than ~3GB of RAM.

Sam

On Nov 12, 2007 11:29 AM, Sam Mason <sam@samason.me.uk> wrote:

On Mon, Nov 12, 2007 at 10:14:46AM -0700, Steve Wampler wrote:

Also, what kernel are you using with CentOS 5 - a 32-bit (with hugemem
to support the 8GB) or a 64-bit? And which was PostgreSQL compiled for?

You don't need a 32bit kernel to support 8GB of memory should you? As
long as the kernel supports PAE that should be enough to make use of it.
You only need a 64bit address space when each process wants to see more
than ~3GB of RAM.

There's a performance hit for using PAE. Not sure what it is, but I
recall it being the in the 5 to 10% range.

On Mon, Nov 12, 2007 at 11:31:59AM -0600, Scott Marlowe wrote:

On Nov 12, 2007 11:29 AM, Sam Mason <sam@samason.me.uk> wrote:

You don't need a 32bit kernel to support 8GB of memory should you? As
long as the kernel supports PAE that should be enough to make use of it.
You only need a 64bit address space when each process wants to see more
than ~3GB of RAM.

There's a performance hit for using PAE. Not sure what it is, but I
recall it being the in the 5 to 10% range.

And what's the performance hit of using native 64bit code? I'd guess
similar, moving twice as much data around with each pointer has got to
affect things.

Sam

Scott Marlowe wrote:

On Nov 12, 2007 11:29 AM, Sam Mason <sam@samason.me.uk> wrote:

You don't need a 32bit kernel to support 8GB of memory should you? As
long as the kernel supports PAE that should be enough to make use of it.
You only need a 64bit address space when each process wants to see more
than ~3GB of RAM.

There's a performance hit for using PAE. Not sure what it is, but I
recall it being the in the 5 to 10% range.

Also, using PAE *used* to require the (OS-internal) use of 'bounce-buffers'
to copy data from processes high-up in memory down to i/o devices low-down
in memory. I don't know if that's still an issue or not with 2.6 kernels,
but I could see it still being the case and, if so, seems like it would have
a significant impact on I/O bound tasks (like most DB processing...)

--
Steve Wampler -- swampler@noao.edu
The gods that smiled on your birth are now laughing out loud.

On Nov 12, 2007 11:37 AM, Sam Mason <sam@samason.me.uk> wrote:

On Mon, Nov 12, 2007 at 11:31:59AM -0600, Scott Marlowe wrote:

On Nov 12, 2007 11:29 AM, Sam Mason <sam@samason.me.uk> wrote:

You don't need a 32bit kernel to support 8GB of memory should you? As
long as the kernel supports PAE that should be enough to make use of it.
You only need a 64bit address space when each process wants to see more
than ~3GB of RAM.

There's a performance hit for using PAE. Not sure what it is, but I
recall it being the in the 5 to 10% range.

And what's the performance hit of using native 64bit code? I'd guess
similar, moving twice as much data around with each pointer has got to
affect things.

That's not been my experience. It's not like everything you do
requires 64 bits to be moved where in 32 bit code only 32 were moved.
The performance gain of the 64 bit machine doing 64 bit operations
over the 32 bit machine doing them (i.e. floating point etc...) is so
much more that it more than makes up for the overhead of running in 64
bit mode.

Sam Mason wrote:

And what's the performance hit of using native 64bit code? I'd guess
similar, moving twice as much data around with each pointer has got to
affect things.

That's probably difficult to predict. Since the architecture is 64-bits,
it shouldn't cost any more to move a 64-bit pointer around as a 32-bit
one. (Plus, I *think* you get more registers in 64-bit mode.)

However, a good optimizer might figure out it can move two 32-bit pointers
with one 64-bit transfer.

--
Steve Wampler -- swampler@noao.edu
The gods that smiled on your birth are now laughing out loud.

"Scott Marlowe" <scott.marlowe@gmail.com> writes:

On Nov 12, 2007 11:37 AM, Sam Mason <sam@samason.me.uk> wrote:

And what's the performance hit of using native 64bit code? I'd guess
similar, moving twice as much data around with each pointer has got to
affect things.

That's not been my experience. It's not like everything you do
requires 64 bits to be moved where in 32 bit code only 32 were moved.
The performance gain of the 64 bit machine doing 64 bit operations
over the 32 bit machine doing them (i.e. floating point etc...) is so
much more that it more than makes up for the overhead of running in 64
bit mode.

Plus, 64-bit mode gives you twice as many CPU registers, which is a
huge win for some algorithms, though in many cases it doesn't make
much of a difference.

-Doug

On Mon, Nov 12, 2007 at 11:46:12AM -0600, Scott Marlowe wrote:

On Nov 12, 2007 11:37 AM, Sam Mason <sam@samason.me.uk> wrote:

And what's the performance hit of using native 64bit code? I'd guess
similar, moving twice as much data around with each pointer has got to
affect things.

That's not been my experience. It's not like everything you do
requires 64 bits to be moved where in 32 bit code only 32 were moved.
The performance gain of the 64 bit machine doing 64 bit operations
over the 32 bit machine doing them (i.e. floating point etc...) is so
much more that it more than makes up for the overhead of running in 64
bit mode.

OK, I'm willing to believe you. It used to be a big misunderstanding
that moving to 64bits automatically speed things up, things like this
change though.

Sam

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 12 Nov 2007 10:47:29 -0700
Steve Wampler <swampler@noao.edu> wrote:

Sam Mason wrote:

And what's the performance hit of using native 64bit code? I'd
guess similar, moving twice as much data around with each pointer
has got to affect things.

That's probably difficult to predict. Since the architecture is
64-bits, it shouldn't cost any more to move a 64-bit pointer around
as a 32-bit one. (Plus, I *think* you get more registers in 64-bit
mode.)

It's all about the registers man... all extra 8 of them. Unless of
course you are running with >8GB of ram, then it is all about the
ability to use more than 2GB of shared memory.

Joshua D. Drake

- --

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHOJndATb/zqfZUUQRAjsLAJ4tzk65jzGRGMv33/voxCrqq7O/UACfQR6R
jO/YsOG+4Opq4y8QgoXrnQg=
=/dNT
-----END PGP SIGNATURE-----

On Nov 12, 2007, at 12:29 PM, Sam Mason wrote:

You only need a 64bit address space when each process wants to see
more
than ~3GB of RAM.

And how exactly do you get that on a 32-bit CPU? Even with PAE
(shudders from memories of expanded/extended RAM in the DOS days), you
still have a 32-bit address space per-process.

On Nov 12, 2007, at 12:01 PM, Greg Smith wrote:

Not the Mac OS BSD. Last time I looked into this OS X was still
dramatically slower than Linux on things like process creation.

On MacOS X, that's the Mach kernel doing process creation, not
anything BSD-ish at all. The BSD flavor of MacOS X is mostly just the
userland experience.

On Mon, Nov 12, 2007 at 05:02:52PM -0500, Vivek Khera wrote:

On Nov 12, 2007, at 12:29 PM, Sam Mason wrote:

You only need a 64bit address space when each process wants to see
more than ~3GB of RAM.

And how exactly do you get that on a 32-bit CPU?

I didn't mean to suggest you could. You can actually hack around it by
performing various kernel specific tricks (mmap()ing different parts of
a large file works under some Unixes) but it's a lot of work and tends
to be difficult and brittle.

Even with PAE
(shudders from memories of expanded/extended RAM in the DOS days), you
still have a 32-bit address space per-process.

Yes, if you've got several clients connected they can each have their
3GB address space in RAM and not swapped out, or you have have lots of
disk cache. Other people can probably comment on what life is actually
on a box like this, I've not had much experience.

Sam

On Fri, 2007-11-09 at 23:55 -0500, Mark Niedzielski wrote:

Our developers run on MacBook Pros w/ 2G memory and our production
hardware is dual dual-Core Opterons w/ 8G memory running CentOS 5. The
Macs perform common and complex Postgres operations in about half the
time of our unloaded production hardware. We've compared configurations
and the production hardware is running a much bigger configuration and
faster disk.

What are we missing? Is there a trick to making AMDs perform? Does
Linux suck compared to BSD?

----
that was an awful lot of discussion without any empirical evidence to
support the original claim.

my understanding was that the lack of threading on OSX made it
especially poor for a DB server (but if I recall correctly, that
information was on MySQL).

Do I smell a plant?

Craig

my understanding was that the lack of threading on OSX made it
especially poor for a DB server

What you're referring to must be that the kernel was essentially
single-threaded, with a single "kernel-funnel" lock. (Because the OS
certainly supported threads, and it was certainly possible to write
highly-threaded applications, and I don't know of any performance problems
with threaded applications.)

This has been getting progressively better, with each release adding more
in-kernel concurrency. Which means that 10.5 probably obsoletes all prior
postgres benchmarks on OS X.

--
Scott Ribe
scott_ribe@killerbytes.com
http://www.killerbytes.com/
(303) 722-0567 voice

Thanks to all for the help - and the sanity check. The problem was in
the test and not in the configuration.

We were using a particularly difficult query as a reference (and fully
understanding that it is a two-dimensional alternative to a proper
benchmark). On our test system each run was with empty caches. The
test on the Mac was with caches loaded. Once we started running the
tests with loaded caches, the tuning parameters started behaving as
expected. In the end we took a 880 second query to 3.4 seconds
(compared to 95 seconds on the Mac).

The key was the fact that large configuration changes drew no measurable
change in performance. And that is when you know you are turning the
wrong knobs!

Scott Marlowe wrote: