Re: Best suiting OS - Mailing list pgsql-performance

On Sun, 4 Oct 2009, Devrim G?ND?Z wrote:

> On Sun, 2009-10-04 at 10:05 -0400, Mark Mielke wrote:
>>
>> RHEL and CentOS are particular bad *right now*. See here:
>>      http://en.wikipedia.org/wiki/RHEL
>>      http://en.wikipedia.org/wiki/CentOS
>>
>> For RHEL, look down to "Release History" and RHEL 5.3 based on
>> Linux-2.6.18, released March, 2007. On the CentOS page you'll see it
>> is
>> dated April, 2007. CentOS is identical to RHEL on purpose, but always
>> 1
>> to 6 months after the RHEL, since they take the RHEL source, re-build
>> it, and then re-test it.
>>
>> Linux is up to Linux-2.6.31.1 right now:
>>      http://www.kernel.org/
>>
>> 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" .

"stability" can mean many things to people

in this case it does _not_ mean 'will it crash' type of stability.

if you do not have a corporate standard distro and your sysadmins are
equally comfortable (or uncomfortable and will get training) with all
distros, then the next question to decide is what your support
requirements are.

some companies insist on having a commercial support contract for anything
that they run. If that is the case then you will run RHEL, SuSE
enterprise, Ubuntu (probably long term support version), or _possibly_
debian with a support contract from a consutant shop.

the next layer (and I believe the more common case) is to not require a
commercial support contract, but do require that any software that you run
be supported by the project/distro with security patches.

In this case you need to look at the support timeframe and the release
cycle.

With Fedora, the support timeframe is 12 months with a release every 6
months. Since you cannot (and should not) upgrade all your production
systems the day a new release comes out, this means that to costantly run
a supported version you must upgrade every 6 months.

With Ubuntu, the support timeframe is 18 months with a release every 6
months. This requires that you upgrade every 12 months to stay supported

With the enterprise/long-term-support versions, the support timeframe is 5
years with a new release every 2-3 years. for these you will need to
upgrade every new release, but can wait a year or two after a release has
been made before doing the upgrade

for Debian stable the support timeframe is 1 year after the next release
(which has historicly had an unpredictable schedule, they are trying to
shift to a 2 year cycle, but they haven't actually done it yet). This
allows you to wait several months after a release before having to do an
upgrade.

another question you have to answer in terms of 'support' is what are the
limitations on replacing software that came with the distro with a new
version yourself. With the commercial support options the answer is
usually 'if you upgrade something you void your support contract'. This
can be a significant problem if the distro cycle is long and you need a
new feature. note that for the kernel a 'new feature' may be support for
new hardware, so this can limit what hardware you can buy. If you insist
on buying your hardware from HP/Dell/IBM/etc this may not be too big a
problem as those hardware vendors also take a significant amount of time
to 'certify' new things. For example, I have been looking for a new
hardware vendor and just discovered that I cannot buy a system from
HP/Dell/IBM that includes a SSD yet.


In my case I run Debian Stable on my servers, but identify 'important'
packages that I will compile myself and keep up to date with the upstream
project rather than running what Debian ships. The kernel is one such
package (I don't necessarily run the latest kernel, but I watch closely
for the vunerabilities discovered and if any are relavent to the
configuration I have, I upgrade). For dedicated database boxes Postgres is
another such package (if a system is primarily used for something else and
that package just needs a SQL database I may stick with the distro default)

David Lang