Re: Best suiting OS - Mailing list pgsql-performance

On 10/04/2009 01:55 PM, Devrim GÜNDÜZ wrote:
> On Sun, 2009-10-04 at 10:05 -0400, Mark Mielke wrote:
>
>> So any comparisons between operating system *distributions* should be
>> fair. Comparing a 2007 release to a 2009 release, for example, is not
>> fair. RHEL / CentOS are basically out of the running right now,
>> because
>> they are so old.
>>
> Some people call these "stability" .
>

Note that if a deployment is running well, and has been running well for
years, there is probably no reasonable justification to change it. My
comments are for *new* deployments. If somebody were to come to you with
a *new* deployment request, what would you recommend? Would you really
recommend RHEL 5 *today*?

Pairing 2009 hardware with a 2007 operating system is not what I would
call "stable". I can show you tickets where RedHat has specifically
state they *will not* update the kernel to better support new hardware,
for fear of breaking support for older hardware. These were for the
hardware we have in our lab right now, installed in August, 2009. All 7
of the machines I installed RHEL 5.3 on *failed* to detect the SATA
controller, and the install process completed at 2 Mbyte/s. After the
machines were up, I discovered the issue is a known issue, and that
RedHat would not patch the problem, but instead suggested a change to
grub.conf. Is this stable? I don't think some people would call this
"stability". It is the opposite - it is using an operating system on
hardware that it was never tested or designed for.

For performance, another annoying thing - the RHEL 5.3 kernel doesn't
support "relatime", so file reads are still scattering inode writes
across the file system for otherwise read-only loads. I think RHEL 5.4
doesn't have this either. They finally back-ported FUSE - but did you
know their 2.6.18 kernel has something like 3000 patches that they
maintain against it? Does this not sound insane? How do you provide
effective support for a kernel that has 3000 back ported patches against it?

For example - if I were to be engineering a new solution to be deployed
in February, 2010, I would seriously consider RHEL 6.0, knowing that
RHEL 6.0 will be "stable" on that hardware for several years. I would
not choose RHEL 5.3, because it would be three years old from the day it
is deployed, and six years old three years from now.

RHEL 5 was great for its time - 2007 and maybe the first half of 2008.
RHEL 5 is now obsolete. For anybody who has tried to compile packages
for RHEL 5 to use leading software with RHEL 5, one will quickly find
that base libraries are missing from RHEL 5 that have existed in other
distributions for years. The one at the tip of my tongue right now is
Subversion with GNOME keyring and/or KDE wallet. Those packages don't
exist, or they are *very* old in RHEL 5. This means compiling my own
GNOME keyring and dependent libraries, and possibly compiling the
binaries with static linkage to make sure they work properly. Why? In
this case, it's because Subversion 1.6.5 is out, but RHEL 5 comes with
Subversion 1.4. Next on my tongue is PHP. Suffice it to say I've had
enough problems trying to use recent software on a 3 year old operating
system.

The point in all of the above is not "don't use RHEL". My point is that
software evolves, and "what is best?" is a moving target. RHEL will be
best 1 year out of 3. For the other 2 years? Something else may well be
better. Anybody who tries to produce benchmarks to "prove" their choice
of OS is better, will only be potentially right *today*. As little as 4
months from now, they might be wrong. RHEL 5 performance today is
probably among the worst of the distributions. RHEL 6 performance in
February, 2010 will probably start out life as one of the best - for a time.

Ok, that is probably enough ranting. I hope my point is valuable to
somebody.

Cheers,
mark

--
Mark Mielke<mark@mielke.cc>