Re: Best suiting OS - Mailing list pgsql-performance
From | Mark Mielke |
---|---|
Subject | Re: Best suiting OS |
Date | |
Msg-id | 4AC8FCC9.7050501@mark.mielke.cc Whole thread Raw |
In response to | Re: Best suiting OS (Devrim GÜNDÜZ <devrim@gunduz.org>) |
Responses |
Re: Best suiting OS
Re: Best suiting OS Re: Best suiting OS Re: Best suiting OS |
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>
pgsql-performance by date: