Thread: Best suiting OS

Hi everyone,
      What is the best Linux flavor for server which runs postgres alone. The postgres must handle greater number of database around 200+. Performance on speed is the vital factor.
Is it FreeBSD, CentOS, Fedora, Redhat xxx??

-Arvind S

On Thu, 1 Oct 2009, S Arvind wrote:
>       What is the best Linux flavor for server which runs postgres alone. The postgres
> must handle greater number of database around 200+. Performance on speed is the vital
> factor.
> Is it FreeBSD, CentOS, Fedora, Redhat xxx??

For starters, FreeBSD isn't Linux at all. Secondly, the other three
options you have listed are all Red Hat versions - not much variety there.

I know that some people swear by Red Hat, but I personally have had
nothing but trouble from such installations, especially when trying to
upgrade to a newer version of Postgres. We have just switched a machine
from Red Hat to Debian because of this very problem. I can heartily
recommend Debian, as it distributes new versions of Postgres very quickly
and allows you to continuously upgrade without any problems. For
comparison, with Red Hat, you will need to upgrade to a whole new
distribution whenever you want updated software, which is a much bigger
undertaking.

As far as performance goes (and someone will probably contradict me here)
all the different Linux distributions should be roughly equivalent, as
long as they are up to date and well tuned.

Matthew

--
 And why do I do it that way? Because I wish to remain sane. Um, actually,
 maybe I should just say I don't want to be any worse than I already am.
         - Computer Science Lecturer

S Arvind wrote:
> Hi everyone,
>       What is the best Linux flavor for server which runs postgres
> alone. The postgres must handle greater number of database around 200+.
> Performance on speed is the vital factor.
> Is it FreeBSD, CentOS, Fedora, Redhat xxx??
>
> -Arvind S
>
I do not know the others, and doubt it makes much difference.

My feelings are that if you are running a server, you want a stable one, not
one that is continuously updated for latest and greatest features. Hence I
would rule out Fedora and its ilk.

If you run Redhat, I would advise the most recent; i.e., Red Hat Enterprise
Linux 5, since they do not add any new features and only correct errors.
CentOS is the same as Red Hat, but you probably get better support from Red
Hat if you need it -- though you pay for it.

--
   .~.  Jean-David Beyer          Registered Linux User 85642.
   /V\  PGP-Key: 9A2FC99A         Registered Machine   241939.
  /( )\ Shrewsbury, New Jersey    http://counter.li.org
  ^^-^^ 05:55:01 up 14:54, 4 users, load average: 5.40, 5.25, 5.04

For example i mentioned few linux name only, if any one linux other then this also u can prescribe. Our servers needs to be more stable one, as Jean told we cant upgrade our OS often. For the Postgres8.3 can u tell me the best one. Factor is purely performance and i/o since our storage server seprate .

Thanks,
Arvind S

"Many of lifes failure are people who did not realize how close they were to success when they gave up."
-Thomas Edison

Matthew Wakeling wrote:

> For starters, FreeBSD isn't Linux at all. Secondly, the other three
> options you have listed are all Red Hat versions - not much variety there.

The main difference between those is that Fedora tries to be the latest and
greatest. This implies that you must reinstall or update about every six
months -- because if you do not wish to do that, you would be running a more
stable distribution.
>
> I know that some people swear by Red Hat, but I personally have had
> nothing but trouble from such installations,

I have no trouble with Red Hat Enterprise Linux or its equivalent, CentOS.
However the following point is valid:

> especially when trying to
> upgrade to a newer version of Postgres.

The theory with the Red Hat Enterprise Linux distribution is that you run
with what comes with it. All the stuff that comes with it is guaranteed to
work together. Red Hat do not add features, change any interfaces, etc. Then
they support it for 7 years. I.e., if it works for you at the beginning, it
will work the entire 7 years if you wish.

If you want newer features, you must upgrade, as with other distributions,
but their upgrades come only about every year and a half, and if you do not
need the new features, you just do not bother. I started with RHEL 3,
skipped RHEL 4 (except I run CentOS 4 on my old machine), and am now running
RHEL 5. Consequently, I am running postgresql-8.1.11-1.el5_1.1 and it works
fine, as it did when I started. They fix only errors, not performance
problems or new features.

> We have just switched a machine
> from Red Hat to Debian because of this very problem. I can heartily
> recommend Debian, as it distributes new versions of Postgres very quickly
> and allows you to continuously upgrade without any problems. For
> comparison, with Red Hat, you will need to upgrade to a whole new
> distribution whenever you want updated software, which is a much bigger
> undertaking.
>



--
   .~.  Jean-David Beyer          Registered Linux User 85642.
   /V\  PGP-Key: 9A2FC99A         Registered Machine   241939.
  /( )\ Shrewsbury, New Jersey    http://counter.li.org
  ^^-^^ 06:05:01 up 15:04, 4 users, load average: 6.01, 5.69, 5.33

Thanks Jean,
     So from the discussion is it true that performance will be same across all newly upgraded linux is it?

Thanks,
Arvind S

"Many of lifes failure are people who did not realize how close they were to success when they gave up."
-Thomas Edison

> Hi everyone,
>       What is the best Linux flavor for server which runs postgres alone.
> The postgres must handle greater number of database around 200+. Performance
> on speed is the vital factor.
> Is it FreeBSD, CentOS, Fedora, Redhat xxx??

As others mention FreeBSD is somewhat different from the others. I
personally prefer FreeBSD because that it what I do best. If you don't
have any prior experiences with FreeBSD/Linux spent some time
installing them and install some ports/apps. Try to become aquainted
with the update tools using the command line interface, csup on
FreeBSD, apt on debian/ubuntu.

--
regards
Claus

When lenity and cruelty play for a kingdom,
the gentler gamester is the soonest winner.

Shakespeare

>-----Original Message-----
>From: pgsql-performance-owner@postgresql.org [mailto:pgsql-performance-
>
>> Hi everyone,
>>       What is the best Linux flavor for server which runs postgres alone.
>> The postgres must handle greater number of database around 200+.
>Performance
>> on speed is the vital factor.
>> Is it FreeBSD, CentOS, Fedora, Redhat xxx??
>
>As others mention FreeBSD is somewhat different from the others. I
>personally prefer FreeBSD because that it what I do best. If you don't
>have any prior experiences with FreeBSD/Linux spent some time
>installing them and install some ports/apps. Try to become aquainted
>with the update tools using the command line interface, csup on
>FreeBSD, apt on debian/ubuntu.

I'm running Postgres on NetBSD and RHEL4.  I haven't noticed any particular differences in Postgres performance due to
theOS, but then again I haven't performed any kind of formal benchmarks, nor am I really stressing the database all
thatmuch (most of the time). 
My preference for OS to run is NetBSD, because I'm most familiar with it and there have been some fairly significant
recentfocus on performance improvements.  If you're really worried about getting the best performance I think you're
justgoing to have to try a few different OSes and see if you notice a difference. 

btw, do you mean 200+ databases in a single postgres server, or that many different postgres servers?   Running 200
differentservers sounds like it might be problematic on any OS due to the amount of shared memory that'll need to be
allocated.

eric

Jean-David Beyer <jeandavid8@verizon.net> writes:
> The theory with the Red Hat Enterprise Linux distribution is that you run
> with what comes with it. All the stuff that comes with it is guaranteed to
> work together. Red Hat do not add features, change any interfaces, etc. Then
> they support it for 7 years. I.e., if it works for you at the beginning, it
> will work the entire 7 years if you wish.

Yeah, RHEL is intended to be a stable application platform: once you set
up your server, it will "just keep working"; you should not have to
worry whether updates will break your application.

It is not entirely a coincidence that this is exactly the attitude
Postgres takes towards our back branches ;-)

            regards, tom lane

Eric thanks.

On Thu, 1 Oct 2009, Matthew Wakeling wrote:

> For comparison, with Red Hat, you will need to upgrade to a whole new
> distribution whenever you want updated software, which is a much bigger
> undertaking.

This is somewhat true for larger packages, but it's not the case for
PostgreSQL.  You certainly can grab newer RPMs from
https://projects.commandprompt.com/public/pgcore and install them.  Those
packages are at least as current as their Debian counterparts, and in some
cases the RPMs have been months ahead (I recall there being quite a lag
before Debian supported PG 8.3 for example).

It can be a bit tricky to replace the RHEL version of PostgreSQL with
those, I wrote a walkthrough that covers the non-obvious parts at
http://www.westnet.com/~gsmith/content/postgresql/pgrpm.htm

The result won't be officially supported by RedHat, but in practice that's
no worse than what you get from the Debian versions.

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

On Thu, 1 Oct 2009, S Arvind wrote:

> What is the best Linux flavor for server which runs postgres alone. The
> postgres must handle greater number of database around 200+. Performance
> on speed is the vital factor.

Generally the fastest Linux distribution is whichever one is built using
the most recent Linux kernel.  The downside of that is that the latest
kernel versions are likely to have nasty bugs in them.

RedHat and CentOS are both based on the 2.6.18 kernel, with some pieces of
later ones patched in there too.  That's pretty old at this point.  What I
do on a lot of systems is install RHEL/CentOS, then compile my own kernel
starting with the same options RedHat did and use that one.  Then I can
adjust exactly how close I am to the latest Linux kernel while still
getting the benefit of the stable package set the rest of the distribution
offers.  Right now I'm using 2.6.30 on a few such systems, that's one rev
back from current (2.6.31 is the latest stable kernel release but it's
still scary new).

The standard kernel on current Ubuntu systems right now is based on
2.6.28, that performs pretty well too.

If what you want is optimized speed and you don't care about any other
trade-off, Gentoo Linux is probably what you want.  You better make sure
you have considerable Linux support expertise available for your project
though.  That's probably true of any high-performance setup though.  Many
of the ways you can make a database system faster are complicated to setup
and require more work to keep going than if you just settled for the
slower but more popular implementation.

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

On Thu, 1 Oct 2009, S Arvind wrote:

> Hi everyone,
>      What is the best Linux flavor for server which runs postgres alone.
> The postgres must handle greater number of database around 200+. Performance
> on speed is the vital factor.
> Is it FreeBSD, CentOS, Fedora, Redhat xxx??

as noted by others *BSD is not linux

among the linux options, the best option is the one that you as a company
are most comfortable with (and have the support/upgrade processes in place
for)

in general, the newer the kernel the better things will work, but it's far
better to have an 'old' system that your sysadmins understand well and can
support easily than a 'new' system that they don't know well and therefor
have trouble supporting.

David Lang

On Thu, Oct 1, 2009 at 3:46 AM, S Arvind <arvindwill@gmail.com> wrote:
> Hi everyone,
>       What is the best Linux flavor for server which runs postgres alone.
> The postgres must handle greater number of database around 200+. Performance
> on speed is the vital factor.
> Is it FreeBSD, CentOS, Fedora, Redhat xxx??

You say you want speed, but I'm betting stability is more important
than speed, as a machine that crashes several times a month but is
lightening fast is usually a bad choice for a db server.

I run Centos 5.3 with an older kernel.  There's a bug in the areca
drivers after the 2.6.18-92.el5 kernel that redhat has no apparent
interest in fixing.  But with that kernel, I have a machine that's
pretty fast and stable:

uname -a
Linux db1 2.6.18-92.el5 #1 SMP Tue Jun 10 18:51:06 EDT 2008 x86_64
x86_64 x86_64 GNU/Linux
uptime
 13:44:38 up 416 days, 28 min,  6 users,  load average: 28.94, 31.93, 32.50

It's twin was the one I tested the newer kernel on and had the hangs
with.  It now runs the same older kernel as well.

> > Hi everyone,
> >       What is the best Linux flavor for server
> which runs postgres alone.
> > The postgres must handle greater number of database
> around 200+. Performance
> > on speed is the vital factor.
> > Is it FreeBSD, CentOS, Fedora, Redhat xxx??


I see nobody suggesting Solaris... ZFS is supposed to be a very nice FS...

> I see nobody suggesting Solaris... ZFS is supposed to be a
> very nice FS...

(of course, it's not a linux flavor...)

On Thu, 1 Oct 2009, Greg Smith wrote:
> On Thu, 1 Oct 2009, Matthew Wakeling wrote:
>> For comparison, with Red Hat, you will need to upgrade to a whole new
>> distribution whenever you want updated software, which is a much bigger
>> undertaking.
>
> This is somewhat true for larger packages, but it's not the case for
> PostgreSQL.  You certainly can grab newer RPMs from
> https://projects.commandprompt.com/public/pgcore and install them.

The reason we switched that machine to Debian was due to the
postgresql-devel package being missing for Red Hat. We need that package
in order to install some of our more interesting extensions. A quick look
at http://yum.pgsqlrpms.org/8.4/fedora/fedora-9-x86_64/ indicates that
this package is still missing. Because Debian includes Postgres in its
main package repository and uses automated build tools, Debian is unlikely
to suffer the same fate.

Matthew

--
 I'm always interested when [cold callers] try to flog conservatories.
 Anyone who can actually attach a conservatory to a fourth floor flat
 stands a marginally better than average chance of winning my custom.
 (Seen on Usenet)

On Fri, 2009-10-02 at 12:39 +0100, Matthew Wakeling wrote:
> The reason we switched that machine to Debian was due to the
> postgresql-devel package being missing for Red Hat. We need that
> package in order to install some of our more interesting extensions. A
> quick look at http://yum.pgsqlrpms.org/8.4/fedora/fedora-9-x86_64/
> indicates that this package is still missing.

Neither Red Hat, nor this repository is missing that package. The link
you gave is the only exception in 14 different combinations, because of
a wrong major cleanup that I performed 2 weeks ago. I re-uploaded -devel
to the repository.

http://mirror.centos.org/centos/5.3/os/x86_64/CentOS/postgresql-devel-8.1.11-1.el5_1.1.i386.rpm

See this as an example to Red Hat (and CentOS),

> Because Debian includes Postgres in its
> main package repository and uses automated build tools, Debian is
> unlikely to suffer the same fate.

This is nonsense. Both Debian, Fedora, Red Hat, CentOS and OpenSUSE has
automated build tools and QA.
--
Devrim GÜNDÜZ, RHCE
Command Prompt - http://www.CommandPrompt.com
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz

Matthew Wakeling <matthew@flymine.org> writes:
> The reason we switched that machine to Debian was due to the
> postgresql-devel package being missing for Red Hat. We need that package
> in order to install some of our more interesting extensions. A quick look
> at http://yum.pgsqlrpms.org/8.4/fedora/fedora-9-x86_64/ indicates that
> this package is still missing.

You switched OSes instead of complaining to the repository maintainer
that he'd forgotten a subpackage?  You must have a lot of time on your
hands.

            regards, tom lane

S Arvind wrote:
> Hi everyone,
>       What is the best Linux flavor for server which runs postgres
> alone. The postgres must handle greater number of database around
> 200+. Performance on speed is the vital factor.
> Is it FreeBSD, CentOS, Fedora, Redhat xxx??
>
> -Arvind S
We use Arch Linux and love it.  It does not have "versions" - you just
keep updating your install and never have to do a major version
upgrade.  It is a bare bones distribution with excellent package
management and repositories, virtually no distribution cruft, and a
fantastic community/wiki/forum.

As a warning no one offers support for Arch that I know of and the
packages are generally very current with the latest which is both a good
and bad thing.  For a production environment you have to be very careful
about when you do upgrades and preferably can test upgrades on QA
machines before running on production.  You also want to make sure and
exclude postgresql from updates so that it doesn't do something like
pull down 8.4 over an 8.3.x installation without you being backed up and
ready to restore.  PostgreSQL is currently at 8.4.1 in their repositories.

With that disclaimer out of the way it is my favorite Linux distribution
and I am running it on a couple dozens servers at the moment ranging
from puny app servers to 8 core, 32GB+ RAM, 30-40 disk database
servers.  If you are comfortable with Linux it is worth checking out (on
your personal machine or QA environment first).  I've run dozens of
distributions and this works well for us (a startup with nontrivial
Linux experience).  I imagine at a larger company it definitely would
not be an option.

Joe Uhl

On Fri, 2 Oct 2009, Tom Lane wrote:
> Matthew Wakeling <matthew@flymine.org> writes:
>> The reason we switched that machine to Debian was due to the
>> postgresql-devel package being missing for Red Hat. We need that package
>> in order to install some of our more interesting extensions. A quick look
>> at http://yum.pgsqlrpms.org/8.4/fedora/fedora-9-x86_64/ indicates that
>> this package is still missing.
>
> You switched OSes instead of complaining to the repository maintainer
> that he'd forgotten a subpackage?  You must have a lot of time on your
> hands.

Camel's back, straw.

Besides, both I and our sysadmin are much more used to Debian. We were
dealing with an old install of RH from our old sysadmin and couldn't be
bothered to work out the Red Hat Way(tm). Much easier to un-switch OSes.

Matthew

--
 I work for an investment bank. I have dealt with code written by stock
 exchanges. I have seen how the computer systems that store your money are
 run. If I ever make a fortune, I will store it in gold bullion under my
 bed.                                              -- Matthew Crosby

On 10/02/2009 10:23 AM, Matthew Wakeling wrote:
> On Fri, 2 Oct 2009, Tom Lane wrote:
>> You switched OSes instead of complaining to the repository maintainer
>> that he'd forgotten a subpackage?  You must have a lot of time on your
>> hands.
>
> Camel's back, straw.
>
> Besides, both I and our sysadmin are much more used to Debian. We were
> dealing with an old install of RH from our old sysadmin and couldn't
> be bothered to work out the Red Hat Way(tm). Much easier to un-switch
> OSes.

... until you move on and leave the company with some hacked up Debian
installs that nobody knows how to manage.

Just throwing that out there. :-)

Cheers,
mark

--
Mark Mielke<mark@mielke.cc>

* Mark Mielke <mark@mark.mielke.cc> [091002 11:41]:

> ... until you move on and leave the company with some hacked up Debian
> installs that nobody knows how to manage.

Could be worse, they could leave a Redhat/CentOS box that *can't* be
managed

emacs anyone?

/duck and run, promising not to post on this again....

--
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

On Thu, Oct 1, 2009 at 4:46 AM, S Arvind <arvindwill@gmail.com> wrote:
> Hi everyone,
>       What is the best Linux flavor for server which runs postgres alone.
> The postgres must handle greater number of database around 200+. Performance
> on speed is the vital factor.
> Is it FreeBSD, CentOS, Fedora, Redhat xxx??

FreeBSD isn't Linux.

I don't recommend that you run Fedora, it undergoes way too much churn.

I don't find any real difference between CentOS and RedHat.

I personally prefer openSUSE (or SLES/SLED if you want their
commerical offering). I find it faster, more up-to-date (but no
"churn"), and in general higher quality - "it just works". I find
postgresql *substantially* faster on openSUSE than CentOS, but that's
purely anecdotal and I don't have any raw numbers to compare.

openSUSE 11.1 has 8.3.8 and 11.2 (not out yet - a few months) will have 8.4.X.

--
Jon

On Fri, 2 Oct 2009, Matthew Wakeling wrote:

> The reason we switched that machine to Debian was due to the
> postgresql-devel package being missing for Red Hat. We need that package
> in order to install some of our more interesting extensions. A quick
> look at http://yum.pgsqlrpms.org/8.4/fedora/fedora-9-x86_64/ indicates
> that this package is still missing.

So you mention that on pgsql-performance, not even close to the most
popular list here, and before I even read your e-mail the missing file is
already fixed because the maintainer reads this and noted a mistake (for
that old and and what is officially a quite unsupported Fedora version).
That seems like a pretty well supported PostgreSQL package set to me, no?

> Besides, both I and our sysadmin are much more used to Debian. We were
> dealing with an old install of RH from our old sysadmin and couldn't be
> bothered to work out the Red Hat Way(tm). Much easier to un-switch OSes.

Ah, here we have your real reason.  It's OK to say "I don't like the Red
Hat Way and am more used to Debian" and have reasons for why that is.
You don't need to sling FUD about the things you didn't even try seriously
to support that.  Packaging is hard work, and I've gotten one-off bad
packages from everybody at some point, including Debian derived ones.
They don't have a magic wand that makes their packages immune to all
possible human error for things the automated tests don't check.

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

On Thu, Oct 1, 2009 at 5:46 AM, S Arvind <arvindwill@gmail.com> wrote:
> Hi everyone,
>       What is the best Linux flavor for server which runs postgres alone.
> The postgres must handle greater number of database around 200+. Performance
> on speed is the vital factor.
> Is it FreeBSD, CentOS, Fedora, Redhat xxx??

I think for linux centos/redhat is probably the best bet.  Debian
would be a good choice too especially if you have developers using
debian based system (like ubuntu) on the desktop. redhat gets the nod
because of hardware support and they are the most serious about
backpatching fixes on enterprise releases.

I know I'm in the minority here, but I _always_ compile postgresql
myself directly from official sources.  It's easy enough and you never
know when you have to do an emergency patch or cassert build, etc.

merlin

On Fri, 2 Oct 2009, Jon Nelson wrote:

> I personally prefer openSUSE (or SLES/SLED if you want their
> commerical offering). I find it faster, more up-to-date (but no
> "churn"), and in general higher quality - "it just works". I find
> postgresql *substantially* faster on openSUSE than CentOS, but that's
> purely anecdotal and I don't have any raw numbers to compare.
> openSUSE 11.1 has 8.3.8 and 11.2 (not out yet - a few months) will have 8.4.X.

As I was saying upthread, statements like this all need to be disclaimed
with the relative default kernel versions involved.

openSUSE 11.1=Kernel 2.6.27
RHEL5=Kernel 2.6.18

You don't need to provide numbers; that kernel sure is faster.  And I can
grab 2.6.27 or later for my CentOS systems, too, if I'm willing to live
outside of the supported envelope.

SUSE SLED also uses the 2.6.27 kernel, which wasn't too bleeding edge in
March 2008 when SLED 11 came out.  RHEL5 came out in March 2007.  If RHEL6
comes out before SUSE 12, they'll leapfrog ahead for a while.  With
versions aimed to live 5 years, you have to be aware of where in that
cycle you are at any time, and right now RHEL5 is halfway through its
lifetime already--and accordingly a bit behind something that came out a
year later as far as performance goes.

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

On Fri, 2 Oct 2009, Merlin Moncure wrote:

> I know I'm in the minority here, but I _always_ compile postgresql
> myself directly from official sources.  It's easy enough and you never
> know when you have to do an emergency patch or cassert build, etc.

That requires one take all of the security update responsibility yourself,
which isn't a trade-off some people want.  In a lot of situations, it's
just plain easier to take minor point release updates through the main
package manager when there's a bug fix release, knowing that the project
policies will never slip something other than bug fixes into that.  I
think many users will never do a patched build or even know what cassert
toggles, and really they'd shouldn't have to.

The trick I suggest people who use packaged builds get familiar with is
knowing that if you run pg_config and look for the CONFIGURE line, you'll
find out exactly what options were used by the builder of the package you
have, when they compiled the server from source for that package.  If
you've been using a packaged build, but now discovered you need to use a
source one instead, you should be able to grab the source, compile with
those same options, and get a compatible server out of it.

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

Merlin Moncure <mmoncure@gmail.com> wrote:

> I know I'm in the minority here, but I _always_ compile postgresql
> myself directly from official sources.  It's easy enough and you
> never know when you have to do an emergency patch or cassert build,
> etc.

A minority, perhaps; but I'm there with you.  ;-)

-Kevin

On 10/02/2009 01:20 PM, Merlin Moncure wrote:
> I know I'm in the minority here, but I _always_ compile postgresql
> myself directly from official sources.  It's easy enough and you never
> know when you have to do an emergency patch or cassert build, etc.
>

+1

I decided to do this as soon as I figured out that configuration options
(such as how datetime is stored - float vs integer) could change from
release to release. I much prefer to keep a stable PostgreSQL, and
upgrade the OS underneath it. It's been several years with this model,
and it's always been very simple to maintain. I recently documented the
instructions for another team and they fit within about 10 lines that
could be cut + pasted.

Cheers,
mark

--
Mark Mielke<mark@mielke.cc>

Greg Smith <gsmith@gregsmith.com> writes:
> The trick I suggest people who use packaged builds get familiar with is
> knowing that if you run pg_config and look for the CONFIGURE line, you'll
> find out exactly what options were used by the builder of the package you
> have, when they compiled the server from source for that package.  If
> you've been using a packaged build, but now discovered you need to use a
> source one instead, you should be able to grab the source, compile with
> those same options, and get a compatible server out of it.

One other point worth making here is that there are *no* open source
OS distributions that intend to make package building difficult or
arcane, or that won't give you the full sources for what they built.
It's worth your time to learn how to do this on whatever system you
prefer to use.  Then, if you're ever in a situation where you really
need patch XYZ right now, you can easily add that patch to the package
sources and rebuild a custom version that will play nicely within the
distro's package system --- right up to being automatically replaced
when the next regular release does come out.

            regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> writes:
> It's worth your time to learn how to do this on whatever system you
> prefer to use.  Then, if you're ever in a situation where you really
> need patch XYZ right now, you can easily add that patch to the package
> sources and rebuild a custom version that will play nicely within the
> distro's package system --- right up to being automatically replaced
> when the next regular release does come out.

I recently had to do just that (local fix a contrib module failure,
pg_freespacemap). It looks like this when you're using debian:

  $ apt-get source postgresql-8.3
  $ cd postgresql-8.3-8.3.7
  $ cp /path/to/patch.diff debian/patches/13-pg_fsm.diff --- pick yourself next available id
  $ $EDITOR debian/changelog
  $ debuild

Now you have a new .deb you want to distribute for upgrades (targeting
preprod first, of course). The changelog editing is best done knowing
what is a NMU and how to represent it there, and how version sorting
works; that's the key to automatic overwrite at next official minor
upgrade, and it allows to put the version under your name, so that you
can GnuPG sign the packages at the end of the debuild process.

  http://www.debian.org/doc/developers-reference/pkgs.html#nmu

Regards,
--
dim

I'm a BSD license fan, but, I don't know much about *BSD otherwise (except that many advocates say it runs PG very nicely).

On Thu, Oct 1, 2009 at 4:46 AM, S Arvind <arvindwill@gmail.com> wrote:
>
> Is it FreeBSD, CentOS, Fedora, Redhat xxx??

FreeBSD isn't Linux.
Don't run Fedora, it undergoes way too much Churn.
No real difference between CentOS and RedHat.

I personally prefer openSUSE (or SLES/SLED if you want their
commerical offering). I find it faster, more up-to-date (but no
"churn"), in general higher quality. I find postgresql *substantially*
faster on openSUSE than CentOS, but that's purely anecdotal and I
don't have any raw numbers to compare.

openSUSE 11.1 has 8.3.8 and 11.2 (not out yet - a few months) will have 8.4.X.

--
Jon

Denis Lussier wrote:

I'm a BSD license fan, but, I don't know much about *BSD otherwise (except that many advocates say it runs PG very nicely).

On the Linux side, unless your a dweeb, go with a newer, popular & well supported release for Production.  IMHO, that's RHEL 5.x or CentOS 5.x.  Of course the latest SLES & UBuntu schtuff are also fine.

In other words, unless you've got a really good reason for it, stay away from Fedora & OpenSuse for production usage.

On Thu, Oct 1, 2009 at 3:10 PM, <david@lang.hm> wrote:

On Thu, 1 Oct 2009, S Arvind wrote:

Hi everyone,
    What is the best Linux flavor for server which runs postgres alone.
The postgres must handle greater number of database around 200+. Performance
on speed is the vital factor.
Is it FreeBSD, CentOS, Fedora, Redhat xxx??

as noted by others *BSD is not linux

among the linux options, the best option is the one that you as a company are most comfortable with (and have the support/upgrade processes in place for)

in general, the newer the kernel the better things will work, but it's far better to have an 'old' system that your sysadmins understand well and can support easily than a 'new' system that they don't know well and therefor have trouble supporting.

David Lang

I am a particular fan of FreeBSD, and in some benchmarking I did between it and CentOS FreeBSD 7.x literally wiped the floor with the CentOS release I tried on IDENTICAL hardware. 
I also like the 3ware raid coprocessors - they work well, are fast, and I've had zero trouble with them.

-- Karl

On 10/01/2009 03:44 PM, Denis Lussier wrote:
> I'm a BSD license fan, but, I don't know much about *BSD otherwise
> (except that many advocates say it runs PG very nicely).
>
> On the Linux side, unless your a dweeb, go with a newer, popular &
> well supported release for Production.  IMHO, that's RHEL 5.x or
> CentOS 5.x.  Of course the latest SLES & UBuntu schtuff are also fine.
>
> In other words, unless you've got a really good reason for it, stay
> away from Fedora & OpenSuse for production usage.

Lots of conflicting opinions and results in this thread. Also, a lot of
hand waving and speculation. :-)

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. However, RHEL 6.0 should be out in January or February,
2010, at which point it will be relevant again.

Personally, I use Fedora, and my servers have been quite stable. One of
our main web servers running Fedora:

[mark@bambi]~% uptime
  09:45:41 up 236 days, 10:07,  1 user,  load average: 0.02, 0.04, 0.08

It was last rebooted as a scheduled reboot, not a crash. This isn't to
say Fedora will be stable for you - however, having used both RHEL and
Fedora, in many different configurations, I find RHEL being 2+ years
behind in terms of being patch-current means that it is NOT as stable on
modern hardware. Most recently, I installed RHEL on a 10 machine cluster
of HP nodes, and RHEL would not detect the SATA controller out of the
box and reverted to some base PIO mode yielding 2 Mbyte/s disk speed.
Fedora was able to achieve 112 Mbyte/s on the same disks. Some twiddling
of grub.conf allowed RHEL to achieve the same speed, but the point is
that there are two ways to de-stabilize a kernel. One is to use the
leading edge, the other is to use the trailing edge. Using an operating
system designed for 2007 on hardware designed in 2009 is a bad idea.
Using an operating system designed for 2009 on 2007 hardware might also
be a bad idea. Using a modern operating system on modern hardware that
the operating system was designed for will give you the best performance
potential. In this case, Fedora 11 with Linux 2.6.30.8 is almost
guaranteed to out-perform RHEL 5.3 with Linux 2.6.18. Where Fedora is
within 1 to 6 months of the leading edge, Ubuntu is within 3 to 9 months
of the leading edge, so Ubuntu will perform more similar to Fedora than
RHEL.

I've given up on the OS war. People use what they are comfortable with.
Comfort lasts until the operating systems screws a person over, at which
point they "hate" it, and switch to something else. It's about passion -
not about actual metrics, capability, reliability, or any of these other
supposed criteria. In my case, I'm comfortable with RedHat, because I've
used it since the '90s, and because I've seen how they hire some of the
best open source developers, and contribute quality releases back to the
community, specifically including our very own Tom Lane and until
recently Alan Cox. Many of their employees have high fame in the open
source / Linux arena. As a result, my passion is for RedHat-based
releases. As I describe earlier, RHEL is too old right now - and I am
looking forward to RHEL 6.0 catching up to the rest of the world again.
I've found Fedora to be a great alternative when I do need to be on the
leading edge.

So - use what you want - but try not to pretend this isn't about
passion. Even between BSD and Linux, I understand they re-use drivers,
or at least knowledge. It's software that runs your computer. If one OS
can give you +2% performance over another for a 3 month period - big
deal - the available hardware can get a lot better than that +2% by
spending a tiny bit more money, or just waiting 3 months. In the case of
RHEL, waiting about 4 months will give you RHEL 6.0 which will be within
3 to 9 months of the leading edge. If you are planning a new deployment
- this might be something to consider. I suggest not going with RHEL 5
at this time...

Cheers,
mark

--
Mark Mielke<mark@mielke.cc>

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" .
--
Devrim GÜNDÜZ, RHCE
Command Prompt - http://www.CommandPrompt.com
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz

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>

On Sun, 4 Oct 2009, Mark Mielke wrote:

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

I use the following systems:
RHEL4
RHEL5
Fedora 11, latest updates and kernels.

Basically, all systems are stable but all of them have "problems":
RHEL4, RHEL5: Old, but proven systems, missing new features and still
bugs that have already been fixed.
Fedora 11: Bleeding edge system, but with new bugs and systems are
getting even slower with newer kernels:-(

Examples are major bugs in latest kernels in the CFQ scheduler:
http://bugzilla.kernel.org/show_bug.cgi?id=13401#c16

Linux kernel slows down:
http://www.theregister.co.uk/2009/09/22/linus_torvalds_linux_bloated_huge/
http://www.phoronix.com/scan.php?page=article&item=fedora_test_2008&num=4

So software will always have either less features or bugs :-) So it is
always a tradeoff between stability and bleeding edge.

Ciao,
Gerhard

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

On Sun, Oct 4, 2009 at 8:05 AM, Mark Mielke <mark@mark.mielke.cc> wrote:
> On 10/01/2009 03:44 PM, Denis Lussier wrote:
>>
>> I'm a BSD license fan, but, I don't know much about *BSD otherwise (except
>> that many advocates say it runs PG very nicely).
>>
>> On the Linux side, unless your a dweeb, go with a newer, popular & well
>> supported release for Production.  IMHO, that's RHEL 5.x or CentOS 5.x.  Of
>> course the latest SLES & UBuntu schtuff are also fine.
>>
>> In other words, unless you've got a really good reason for it, stay away
>> from Fedora & OpenSuse for production usage.
>
> Lots of conflicting opinions and results in this thread. Also, a lot of hand
> waving and speculation. :-)
>
> 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.
> However, RHEL 6.0 should be out in January or February, 2010, at which point
> it will be relevant again.

It's completely fair.  I have a Centos 5.2 machine with 430 or so days
of uptime.  I put it online, tested it and had it ready 430 days ago
and it's crashed / hung exactly zero times since.  You're right.  It's
completely unfair to compare some brand new kernel with unknown
bugginess and stability issues to my 5.2 machine.  Oh wait, you're
saying Centos is out of the running because it's old?  That's 110%
backwards from the way a DBA should be thinking.  First make it
stable, THEN look for ways to make it performance.  A DB server with
stability issues is completely useless in a production environment.

> Personally, I use Fedora, and my servers have been quite stable. One of our
> main web servers running Fedora:

It's not that there can't be stable releases of FC, it's that it's not
the focus of that project.  So, if you get lucky, great!  I can't
imagine running a production DB on FC, with it's short supported life
span and focus on development and not stability.

> [mark@bambi]~% uptime
>  09:45:41 up 236 days, 10:07,  1 user,  load average: 0.02, 0.04, 0.08
>
> It was last rebooted as a scheduled reboot, not a crash. This isn't to say
> Fedora will be stable for you - however, having used both RHEL and Fedora,
> in many different configurations, I find RHEL being 2+ years behind in terms
> of being patch-current means that it is NOT as stable on modern hardware.

It is NOT 2+ years behind on patches.  Any security issues or bugs
that show up get patched.  Performance enhancing architectural changes
get to wait for the next version (RHEL6).

> Most recently, I installed RHEL on a 10 machine cluster of HP nodes, and
> RHEL would not detect the SATA controller out of the box and reverted to
> some base PIO mode yielding 2 Mbyte/s disk speed.

Yes, again,  RHEL is focused on making stable, already production
capable hardware stay up, and stay supported for 5 to 7 years.  It's a
different focus.

> Fedora was able to achieve
> 112 Mbyte/s on the same disks. Some twiddling of grub.conf allowed RHEL to
> achieve the same speed, but the point is that there are two ways to
> de-stabilize a kernel. One is to use the leading edge, the other is to use
> the trailing edge.

Sorry, but your argument does not support this point.  RHEL took
twiddling to work with the SATA ports.

> Using an operating system designed for 2007 on hardware
> designed in 2009 is a bad idea.

Depends on whether or not it's using the latest and greatest or if
RHEL has back patched support for newer hardware.  Using RHEL on
hardware that isn't officially supported is a bad idea.  I agree about
halfway here, but not really.  I have brand new machines running
Centos 5.2 with no problem.

>Using an operating system designed for 2009
> on 2007 hardware might also be a bad idea.

I think you have to go further back.  Unlike Vista, Linux kernels tend
to support older hardware for a very long time.

> Using a modern operating system
> on modern hardware that the operating system was designed for will give you
> the best performance potential.

True.  But you have to test it hard and prove it's reliable first,
cause it really doesn't matter how fast it crashes.

> In this case, Fedora 11 with Linux 2.6.30.8
> is almost guaranteed to out-perform RHEL 5.3 with Linux 2.6.18. Where Fedora
> is within 1 to 6 months of the leading edge, Ubuntu is within 3 to 9 months
> of the leading edge, so Ubuntu will perform more similar to Fedora than
> RHEL.

And on more exotic hardware (think 8 sockets of 6 core CPUs 128G RAM
and $1400 RAID controllers) it's usually much less well tested yet,
and more likely to bite you in the but.  Nothing like waking up to a
production issue where 46 of your 48 cores are stuck spinning at 100%
with some wonderful new kernel bug that's gonna take 6 months to get a
fix to.  I'll stick to 15% slower but never crashing.  I'll test the
new OS for sure, but I won't trust it enough to put it into production
until it's had a month or more of testing to prove it works.  And with
FC, that's a large chunk of its support lifespan.

> I've given up on the OS war. People use what they are comfortable with.

No, I'm not a huge fan of RHEL.  I'd prefer to run debian or ubuntu on
my servers, but both had some strange bug with multicore systems last
year, and I was forced to run Centos to get a stable machine.  I'll
take a look at Solaris / Open Solaris when I get a chance.  And
FreeBSD now too.  What I'm comfortable with will only matter if it's
stable and reliable and supportable.

> Comfort lasts until the operating systems screws a person over, at which
> point they "hate" it, and switch to something else. It's about passion - not
> about actual metrics, capability, reliability, or any of these other
> supposed criteria.

Sorry, but you obviously don't know me, and I'm guessing a lot of
people on this list, well enough to make that judgement.  Maybe for
some folks comfort is what matters.  For professionals it's not that
at all.  It's about stability, reliability, and performance.  Comfort
is something we just hope we can get in the deal too.

This is kind of OT, unless somebody really is concerned with
understanding the + and - of distributions, and is willing to believe
the content of this thread as being accurate and objective... :-)

On 10/04/2009 08:42 PM, Scott Marlowe wrote:
> On Sun, Oct 4, 2009 at 8:05 AM, Mark Mielke<mark@mark.mielke.cc>  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.
>> However, RHEL 6.0 should be out in January or February, 2010, at which point
>> it will be relevant again.
>>
> It's completely fair.  I have a Centos 5.2 machine with 430 or so days
> of uptime.  I put it online, tested it and had it ready 430 days ago
> and it's crashed / hung exactly zero times since.  You're right.  It's
> completely unfair to compare some brand new kernel with unknown
> bugginess and stability issues to my 5.2 machine.  Oh wait, you're
> saying Centos is out of the running because it's old?  That's 110%
> backwards from the way a DBA should be thinking.  First make it
> stable, THEN look for ways to make it performance.  A DB server with
> stability issues is completely useless in a production environment.
>

Maybe - if the only thing the server is running is PostgreSQL. Show of
hands - how many users who ONLY install PostgreSQL, and use a bare
minimum OS install, choosing to not run any other software? Now, how
many people ALSO run things like PHP, and require software more
up-to-date than 3 years?

>> Personally, I use Fedora, and my servers have been quite stable. One of our
>> main web servers running Fedora:
>>
> It's not that there can't be stable releases of FC, it's that it's not
> the focus of that project.  So, if you get lucky, great!  I can't
> imagine running a production DB on FC, with it's short supported life
> span and focus on development and not stability.
>

Depends on requirements. If the application is frozen in time and
doesn't change - sure. If the application keeps evolving and benefits
from new base software - to require an upgrade every 12 months or more
out of *application* requirements (not even counting OS support
requirements), may not be unusual. In any case - I'm not telling you to
use Fedora. I'm telling you that I use Fedora, and that RHEL 5 is too
old from an application software perspective for anybody with a
requirement on more than a handful of base OS packages.

>> [mark@bambi]~% uptime
>>   09:45:41 up 236 days, 10:07,  1 user,  load average: 0.02, 0.04, 0.08
>>
>> It was last rebooted as a scheduled reboot, not a crash. This isn't to say
>> Fedora will be stable for you - however, having used both RHEL and Fedora,
>> in many different configurations, I find RHEL being 2+ years behind in terms
>> of being patch-current means that it is NOT as stable on modern hardware.
>>
> It is NOT 2+ years behind on patches.  Any security issues or bugs
> that show up get patched.  Performance enhancing architectural changes
> get to wait for the next version (RHEL6).
>

Not true. They only backport things considered "important". BIND might
be updated. Firefox might be updated. Most packages see no updates. Some
packages see many updates. As I said - the kernel has something like
3000 patches applied against it (although that's a small subset of all
of the changes made to the upstream kernel). It is not true that "any
security issues or bugs that show up get patched." *Some* security
issues or bugs that show up get patched. If they patched everything
back, they wouldn't have a stable release. Also, they cross this line -
performance enhancing architectural changes *are* made, but only if
there is sufficient demand from the customer base. XFS, EXT4, and FUSE
made it into RHEL 5.4. Even so, plenty of open source software is
difficult or impossible to compile for RHEL 5 without re-compiling base
packages or bringing them in from another source. Try compiling
Subversion 1.6.5 with GNOME keyring support on RHEL 5.3 - that was the
last one that busted us. In fact, this one is still open for us.


>> Most recently, I installed RHEL on a 10 machine cluster of HP nodes, and
>> RHEL would not detect the SATA controller out of the box and reverted to
>> some base PIO mode yielding 2 Mbyte/s disk speed.
>>
> Yes, again,  RHEL is focused on making stable, already production
> capable hardware stay up, and stay supported for 5 to 7 years.  It's a
> different focus.
>

Yes, exactly. Which is why a new deployment should align against the
RHEL release. Deploying RHEL 5 today, when RHEL 5 is 3 years old, and
RHEL 6 is coming out in 4 months, means that your RHEL 5 install is not
going to have 5 to 7 years of life starting today. Half the support life
has almost elapsed at this point.

>> Fedora was able to achieve
>> 112 Mbyte/s on the same disks. Some twiddling of grub.conf allowed RHEL to
>> achieve the same speed, but the point is that there are two ways to
>> de-stabilize a kernel. One is to use the leading edge, the other is to use
>> the trailing edge.
>>
> Sorry, but your argument does not support this point.  RHEL took
> twiddling to work with the SATA ports.
>

You don't even know what the twiddling is - so not sure what you mean by
"support". Do you think it is a well tested configuration from an RHEL
perspective? If an OS can be considered to "support" hardware, if
twiddling in grub.conf will get it to work - then we may as well
conclude that all Linux distributions "support" most or all hardware,
and that they are all "stable". I think it "works", I don't think it is
stable. Every time I upgrade the kernel, I have to watch and make sure
that it still works on next boot, and that grubby has propagated my
grub.conf hack forwards to the next install. Great. Makes me feel REAL
comfortable that my configuration is "supported". (Sarcastic in case it
wasn't obvious).


>> Using an operating system designed for 2007 on hardware
>> designed in 2009 is a bad idea.
>>
> Depends on whether or not it's using the latest and greatest or if
> RHEL has back patched support for newer hardware.  Using RHEL on
> hardware that isn't officially supported is a bad idea.  I agree about
> halfway here, but not really.  I have brand new machines running
> Centos 5.2 with no problem.
>

We also had some HP machines with fancy video cards (dual-headed HDMI
something or other) which I can't even get X to work on with RHEL or
with Fedora, and the machines are probably from ~2006. It depends on if
you stick to standard commodity hardware or fancy obscure stuff. In my
case, I just switched to run level 3 as these were only going to be used
to test some install processes, and were not going to be used as
graphical desktops any ways.

Back in 2006 when I decided on Fedora 8 for one of my servers, it was
because RHEL/CentOS 4.x and Ubuntu would not detect my RAID controller
properly no matter what I tried, and Fedora worked out of the box.

Different people have different experiences. Obviously, so research
and/or lucky choices can improve the odds of a success - but it's sort
of difficult for an operating system to predict what sort of hardware
enhancement will come along two years from now, and prepare for it. Some
enhancements like DDR3 come for free. Other enhancements, such as hyper
threading, turn out to result in disaster. (For those that didn't follow
the HT problems - many operating systems treated the HT as an
independent core, and it could result in two CPU-heavy processes being
assigned to the same single core, leaving the other core idle)

SATA/SAS is one that affected lots of platforms, and affected me as I
described. The BIOS usually has some sort of "legacy IDE" mode where it
let's the SATA pretend to be IDE - but this loses many of the benefits
of SATA. For example, my Fedora installs are benefitting from NCQ,
whereas the RHEL 5.3 installs on the same hardware do not know how to
use NCQ.

You might be fine with CentOS 5.2 on your modern hardware - but I
suspect that your CentOS 5.2 is not making the absolute best use of your
modern hardware. For busy servers, I find "relatime" to be essential.
With CentOS 5.2 - you don't even have that option available to you, and
it has nothing to do with hardware capabilities. You server is busy
scattering writes across your platters for no benefit to you.

>> Using a modern operating system
>> on modern hardware that the operating system was designed for will give you
>> the best performance potential.
>>
> True.  But you have to test it hard and prove it's reliable first,
> cause it really doesn't matter how fast it crashes.
>

I think it's prudent to "test it hard" no matter what configuration you
have selected - whether latest available hardware / software, or whether
hardware and software that is 3 years old. It's your (and mine)
reputation on the line. I certainly wouldn't say "eh, the hardware and
software is two years old - of course it will work!", and I bet you
wouldn't either.

>> In this case, Fedora 11 with Linux 2.6.30.8
>> is almost guaranteed to out-perform RHEL 5.3 with Linux 2.6.18. Where Fedora
>> is within 1 to 6 months of the leading edge, Ubuntu is within 3 to 9 months
>> of the leading edge, so Ubuntu will perform more similar to Fedora than
>> RHEL.
>>
> And on more exotic hardware (think 8 sockets of 6 core CPUs 128G RAM
> and $1400 RAID controllers) it's usually much less well tested yet,
> and more likely to bite you in the but.  Nothing like waking up to a
> production issue where 46 of your 48 cores are stuck spinning at 100%
> with some wonderful new kernel bug that's gonna take 6 months to get a
> fix to.  I'll stick to 15% slower but never crashing.  I'll test the
> new OS for sure, but I won't trust it enough to put it into production
> until it's had a month or more of testing to prove it works.  And with
> FC, that's a large chunk of its support lifespan.
>

Yeah - I wouldn't use a "deskop OS" on server hardware without making
sure it worked. I doubt Fedora or Ubuntu are heavily tested on exotic
hardware such as you describe. For anybody not willing to do some
testing, you are definitely right.

>> I've given up on the OS war. People use what they are comfortable with.
>>
> No, I'm not a huge fan of RHEL.  I'd prefer to run debian or ubuntu on
> my servers, but both had some strange bug with multicore systems last
> year, and I was forced to run Centos to get a stable machine.  I'll
> take a look at Solaris / Open Solaris when I get a chance.  And
> FreeBSD now too.  What I'm comfortable with will only matter if it's
> stable and reliable and supportable.
>

Unfortunately, my ventures into Debian/Ubuntu had the same results. The
last time I tried, it wouldn't grok my desired RAID configuration. I
gave it a real try too. Oh well.

Solaris is good - but I think it doesn't have the ability to sustain
market share. I'm not investing any of my efforts into it. Of course, I
put FreeBSD into that category as well. Maybe I'm prejudiced. :-)

>> Comfort lasts until the operating systems screws a person over, at which
>> point they "hate" it, and switch to something else. It's about passion - not
>> about actual metrics, capability, reliability, or any of these other
>> supposed criteria.
>>
> Sorry, but you obviously don't know me, and I'm guessing a lot of
> people on this list, well enough to make that judgement.  Maybe for
> some folks comfort is what matters.  For professionals it's not that
> at all.  It's about stability, reliability, and performance.  Comfort
> is something we just hope we can get in the deal too.
>

It might be venturing on insult, although it isn't meant to be - but I
think if any of you or us is honest about it - you and I have no idea
whether our installations are truly reliability. They work until they
don't. We cannot see the future. We draw up our own conclusions on what
criteria makes a "reliable" system. We read up on statistics and the
reviews done by others and come to a conclusion. We do our best - but
ultimately, we're guessing. We're using our judgement - we're choosing
what conclusion we are comfortable with. We're comfortable until our
hardware / software betrays us, at which point we feel hurt, and we
decide between forgiving the betrayal or boycotting the configuration. :-)

The best advice of all is your advice earlier above. "Test it hard". Try
and make it fail. Do a good enough job here, and it is more data / less
faith in our conclusions. :-)

The configuration can still fail, though. I would even expect it. I
prefer to assume failure and focus on a contingency plan. I know my
disks and power supplies are going to fail. I know my database will be
corrupted. How do I minimize the impact when such a thing does occur, as
it eventually will?

Cheers,
mark

--
Mark Mielke<mark@mielke.cc>

Scott Marlowe wrote:
>> Personally, I use Fedora, and my servers have been quite stable. One of our
>> main web servers running Fedora:
>
> It's not that there can't be stable releases of FC, it's that it's not
> the focus of that project.  So, if you get lucky, great!  I can't
> imagine running a production DB on FC, with it's short supported life
> span and focus on development and not stability.

I use Fedora, and it was a mistake. I am looking for a better solution.  Fedora has been very stable (uptime of 430
dayson one server), BUT... 

Realistically, the lifetime of a release is as low as SIX MONTHS.  We bought servers just as a FC release was coming
out,and thought we'd be safe by going with the older, tested release.  But six months after that, the next FC release
cameout, and the version we'd installed fell off the support list. 

It takes almost no time with Fedora to run into big problems.  Maybe there's a security release of ssh, you try to
compileit, but it needs the latest gcc, but that's not available on your unsupported version of FC that you installed
lessthan a year ago. 

Or maybe you need a new version of PHP to pass audit with your credit-card processor, but again, your FC release isn't
supportedso you have to uninstall the FC PHP, get the source, and compile PHP from scratch ... on and on it goes. 

Fedora is a very nice project, but it's not suitable for production database servers.

This discussion has been very helpful indeed, and we appreciate everyone's contributions.  I'm leaning towards a stable
Debianrelease for our next upgrade, but there are several other well-reasoned suggestions here. 

Craig

On Sun, 2009-10-04 at 15:51 -0400, Mark Mielke wrote:
> How do you provide  effective support for a kernel that has 3000 back
> ported patches against it?

This is again nonsense. Red Hat employs top kernel hackers. They do
maintain vanilla kernel. It is not hard for Red Hat to maintain their
"own version" ;)
--
Devrim GÜNDÜZ, RHCE
Command Prompt - http://www.CommandPrompt.com
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz

On Thu, 2009-10-01 at 15:16 +0530, S Arvind wrote:
>       What is the best Linux flavor for server which runs postgres
> alone. The postgres must handle greater number of database around 200
> +. Performance on speed is the vital factor.
> Is it FreeBSD, CentOS, Fedora, Redhat xxx??

Go for Debian:
* It is a free community, very active.
* It is guaranteed to be upgradable.
* Very easy to administrate via apt-get.

Choose Debian SID or testing, which will provide the latest fixes.

Kind regards,
JMP

On Sun, 2009-10-04 at 15:51 -0400, Mark Mielke wrote:
> If somebody were to come to you with  a *new* deployment request, what
> would you recommend? Would you really  recommend RHEL 5 *today*?

Well, "I" would, and I do recommend people. RHEL5 is well-tested, and
stable. Many hardware vendors support RHEL 5. The list goes on.

If I would want to live with bleeding edge, I'd use Fedora in my
servers. Otherwise, linux 2.6.31 is not *that much* better than Red
Hat's 2.6.18. Actually the point is: Red Hat's 2.6.18 is not actually
2.6.18.

I also want to state that Red Hat is adding new features to each point
release, as you know. It is not that old.

We have a customer that run ~ 1 hundred million transaction/hour , and
they run RHEL. We also have another one that runs about that one, and
guess which OS they are running?

If I weren't using RHEL, I'd use Ubuntu. Nothing else.

...and disclaimer: I don't work for Red Hat.
--
Devrim GÜNDÜZ, RHCE
Command Prompt - http://www.CommandPrompt.com
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz

On Mon, 2009-10-05 at 12:07 +0200, Jean-Michel Pouré wrote:
> Go for Debian:
> * It is a free community, very active.

Well, we need to state that this is not a unique feature.

> * It is guaranteed to be upgradable.

Depends. I had lots of issues with upgrade process in the past -- but
yeah, it is much better than most distros.

> * Very easy to administrate via apt-get.

Right. apt is better than yum (in terms of speed).

> Choose Debian SID or testing, which will provide the latest fixes.

One thing that I don't like about Debian is their update policy.

If upstream is releasing a security update, I'd like to be able to find
new packages as upstream announces updated sets. Yes, I'm talking about
PostgreSQL here.
--
Devrim GÜNDÜZ, RHCE
Command Prompt - http://www.CommandPrompt.com
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz

On Sun, 2009-10-04 at 10:05 -0400, Mark Mielke wrote:
> On 10/01/2009 03:44 PM, Denis Lussier wrote:
> > I'm a BSD license fan, but, I don't know much about *BSD otherwise
> > (except that many advocates say it runs PG very nicely).
> > On the Linux side, unless your a dweeb, go with a newer, popular &
> > well supported release for Production.  IMHO, that's RHEL 5.x or
> > CentOS 5.x.  Of course the latest SLES & UBuntu schtuff are also fine.
> > In other words, unless you've got a really good reason for it, stay
> > away from Fedora & OpenSuse for production usage.
> Lots of conflicting opinions and results in this thread. Also, a lot of
> hand waving and speculation. :-)
> RHEL and CentOS are particular bad *right now*. See here:
>      http://en.wikipedia.org/wiki/RHEL
>      http://en.wikipedia.org/wiki/CentOS

Talk about "hand waving and speculation" - you are citing Wikipedia as a
source?!

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

Maybe that is the kernel version - but it isn't a vanilla kernel.
Comparing kernel versions between distros is a dodgy business as they
all have their own patch sets and backports of patches.

> Linux is up to Linux-2.6.31.1 right now:
>      http://www.kernel.org/

And I very much doubt kernel version is a significant factor in
performance unless you hit one of the lemon versions.

> Personally, I use Fedora, and my servers have been quite stable. One of
> our main web servers running Fedora:
> [mark@bambi]~% uptime
>   09:45:41 up 236 days, 10:07,  1 user,  load average: 0.02, 0.04, 0.08

gourd-amber:~ # uptime
  8:28am  up 867 days 12:30,  1 user,  load average: 0.24, 0.18, 0.10

> Maybe - if the only thing the server is running is PostgreSQL. Show of
> hands - how many users who ONLY install PostgreSQL, and use a bare
> minimum OS install, choosing to not run any other software? Now, how
> many people ALSO run things like PHP, and require software more
> up-to-date than 3 years?

Me.

Not everyone is running LA?P stack applications.

On Mon, Oct 5, 2009 at 2:00 AM, Craig James <craig_james@emolecules.com> wrote:
> Fedora is a very nice project, but it's not suitable for production database
> servers.

The trick is to write such a kick-ass application that before the
Fedora support window ends, the load has increased enough that it's
time to upgrade the hardware anyway.

Also, I'd just like to mention that vi is a much better editor than emacs.

...Robert

Robert Haas wrote (in part):

> Also, I'd just like to mention that vi is a much better editor than
> emacs.
>
That is not my impression. I have used vi from when it first came out (I
used ed before that) until about 1998 when I first installed Linux on one of
my machines and started using emacs. I find that for some tasks involving
global editing, that vi is a lot easier to use. But for most of the things I
do on a regular basis, if find emacs better. So, for me, it is not which is
the better editor, but which is the better editor for the task at hand.

--
   .~.  Jean-David Beyer          Registered Linux User 85642.
   /V\  PGP-Key: 9A2FC99A         Registered Machine   241939.
  /( )\ Shrewsbury, New Jersey    http://counter.li.org
  ^^-^^ 09:30:01 up 4 days, 18:29, 3 users, load average: 4.09, 4.07, 4.09

On Mon, 2009-10-05 at 09:37 -0400, Jean-David Beyer wrote:
> Robert Haas wrote (in part):
> > Also, I'd just like to mention that vi is a much better editor than
> > emacs.
> That is not my impression. I have used vi from when it first came out (I
> used ed before that) until about 1998 when I first installed Linux on one of
> my machines and started using emacs. I find that for some tasks involving
> global editing, that vi is a lot easier to use. But for most of the things I
> do on a regular basis, if find emacs better. So, for me, it is not which is
> the better editor, but which is the better editor for the task at hand.

Both vi and emacs are obsolete.  Bow before the glory of gedit!

Hi Jean-David,

On Mon, 2009-10-05 at 15:37 +0200, Jean-David Beyer wrote:
> Robert Haas wrote (in part):
>
> > Also, I'd just like to mention that vi is a much better editor than
> > emacs.
> >
> That is not my impression. I have used vi from when it first came out (I
> used ed before that) until about 1998 when I first installed Linux on one of
> my machines and started using emacs. I find that for some tasks involving
> global editing, that vi is a lot easier to use. But for most of the things I
> do on a regular basis, if find emacs better. So, for me, it is not which is
> the better editor, but which is the better editor for the task at hand.

You are probably absolutely right, but Robert only wanted to point out
that this conversation gets in the flame-war direction, in his subtle
way of doing this...

Cheers,
Csaba.

Devrim GÜNDÜZ wrote:
> On Mon, 2009-10-05 at 12:07 +0200, Jean-Michel Pouré wrote:
>> Go for Debian:
>> * It is a free community, very active.
>
> Well, we need to state that this is not a unique feature.
>
>> * It is guaranteed to be upgradable.
>
> Depends. I had lots of issues with upgrade process in the past -- but
> yeah, it is much better than most distros.
>
>> * Very easy to administrate via apt-get.
>
> Right. apt is better than yum (in terms of speed).
>
>> Choose Debian SID or testing, which will provide the latest fixes.
>
> One thing that I don't like about Debian is their update policy.
>
> If upstream is releasing a security update, I'd like to be able to find
> new packages as upstream announces updated sets. Yes, I'm talking about
> PostgreSQL here.

This is exactly what Debian does for a while now(at least for PostgreSQL)..
Ie.: Debian Etch aka  has 8.1.18 and Debian Lenny has 8.3.8...


Stefan

Stefan Kaltenbrunner wrote:
> Devrim GÜNDÜZ wrote:
>> On Mon, 2009-10-05 at 12:07 +0200, Jean-Michel Pouré wrote:
>>> Go for Debian:
>>> * It is a free community, very active.
>>
>> Well, we need to state that this is not a unique feature.
>>
>>> * It is guaranteed to be upgradable.
>>
>> Depends. I had lots of issues with upgrade process in the past -- but
>> yeah, it is much better than most distros.
>>
>>> * Very easy to administrate via apt-get.
>>
>> Right. apt is better than yum (in terms of speed).
>>
>>> Choose Debian SID or testing, which will provide the latest fixes.
>>
>> One thing that I don't like about Debian is their update policy.
>>
>> If upstream is releasing a security update, I'd like to be able to find
>> new packages as upstream announces updated sets. Yes, I'm talking about
>> PostgreSQL here.
>
> This is exactly what Debian does for a while now(at least for PostgreSQL)..
> Ie.: Debian Etch aka  has 8.1.18 and Debian Lenny has 8.3.8...

"Debian Etch aka oldstable" and Debian Lenny (the current release)...


Stefan

On 10/3/09 7:35 PM, "Karl Denninger" <karl@denninger.net> wrote:

> Denis Lussier wrote:
>> I'm a BSD license fan, but, I don't know much about *BSD otherwise (except
>> that many advocates say it runs PG very nicely).
>>
>>
>>
>> On the Linux side, unless your a dweeb, go with a newer, popular & well
>> supported release for Production.  IMHO, that's RHEL 5.x or CentOS 5.x.  Of
>> course the latest SLES & UBuntu schtuff are also fine.
>>
>>
>>
>>
>> In other words, unless you've got a really good reason for it, stay away from
>> Fedora & OpenSuse for production usage.
>>
>>
>>
>> On Thu, Oct 1, 2009 at 3:10 PM, <david@lang.hm> wrote:
>>
>>> On Thu, 1 Oct 2009, S Arvind wrote:
>>>
>>>
>>>> Hi everyone,
>>>>     What is the best Linux flavor for server which runs postgres alone.
>>>> The postgres must handle greater number of database around 200+.
>>>> Performance
>>>> on speed is the vital factor.
>>>> Is it FreeBSD, CentOS, Fedora, Redhat xxx??
>>>>
>>>
>>> as noted by others *BSD is not linux
>>>
>>> among the linux options, the best option is the one that you as a company
>>> are most comfortable with (and have the support/upgrade processes in place
>>> for)
>>>
>>> in general, the newer the kernel the better things will work, but it's far
>>> better to have an 'old' system that your sysadmins understand well and can
>>> support easily than a 'new' system that they don't know well and therefor
>>> have trouble supporting.
>>>
>>> David Lang
>>>
>>
>>
>>
> I am a particular fan of FreeBSD, and in some benchmarking I did between it
> and CentOS FreeBSD 7.x literally wiped the floor with the CentOS release I
> tried on IDENTICAL hardware.
> I also like the 3ware raid coprocessors - they work well, are fast, and I've
> had zero trouble with them.
>
> -- Karl
>

With CentOS 5.x, I have to do quite a bit of tuning to get it to perform
well.  I often get almost 2x the performance after tuning.

For I/O --
Deadline scheduler + reasonably large block device read-ahead + XFS
configured with large 'allocsize' settings (8MB to 80MB) make a huge
difference.

Furthermore, the 3ware 35xx and 36xx (I think) I tried performed
particularly badly out of the box without tuning on CentOS.

So, Identical hardware or not, both have to be tuned well to really compare
anyway.

However, I have certainly seen some inefficiencies with Linux and large use
of shared memory -- and I wouldn't be surprised if these problems don't
exist on FreeBSD or OpenSolaris.

Scott Carey wrote:

On 10/3/09 7:35 PM, "Karl Denninger" <karl@denninger.net> wrote: 

I am a particular fan of FreeBSD, and in some benchmarking I did between it
and CentOS FreeBSD 7.x literally wiped the floor with the CentOS release I
tried on IDENTICAL hardware.
I also like the 3ware raid coprocessors - they work well, are fast, and I've
had zero trouble with them.

-- Karl   

With CentOS 5.x, I have to do quite a bit of tuning to get it to perform
well.  I often get almost 2x the performance after tuning.

For I/O --
Deadline scheduler + reasonably large block device read-ahead + XFS
configured with large 'allocsize' settings (8MB to 80MB) make a huge
difference.

Furthermore, the 3ware 35xx and 36xx (I think) I tried performed
particularly badly out of the box without tuning on CentOS.

So, Identical hardware or not, both have to be tuned well to really compare
anyway.

However, I have certainly seen some inefficiencies with Linux and large use
of shared memory -- and I wouldn't be surprised if these problems don't
exist on FreeBSD or OpenSolaris. 

I don't run the 3x series 3ware boards.  If I recall correctly they're not true coprocessor boards and rely on the host CPU.  Those are always going to be a lose compared to a true coprocessor with dedicated cache memory on the card.

The 9xxx series boards are, and are extremely fast (make sure you install the battery backup or run on a UPS, set the appropriate flags, and take your chances - writeback caching makes a HUGE difference.)

Other than pinning shared memory on FreeBSD (and increasing a couple of boot-time tunables to permit large enough shared segments and semaphore lists) little is required to get excellent performance.

The LSI cards that DELL, Intel and a few others have used (these appear to be deprecated now as it looks like LSI bought 3ware) also work well but their user interface is somewhat of a pain in the butt compared to 3Ware's.

-- Karl

> However, I have certainly seen some inefficiencies with Linux and large use
> of shared memory -- and I wouldn't be surprised if these problems don't
> exist on FreeBSD or OpenSolaris.

This came on the freebsd-performance-list a few days ago.

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=13001+0+current/freebsd-performance

--
regards
Claus

When lenity and cruelty play for a kingdom,
the gentler gamester is the soonest winner.

Shakespeare

On 10/5/09 10:27 AM, "Karl Denninger" <karl@denninger.net> wrote:

> Scott Carey wrote:
>>
>>
>> On 10/3/09 7:35 PM, "Karl Denninger" <karl@denninger.net>
>> <mailto:karl@denninger.net>  wrote:
>>
>>
>>
>>>
>>> I am a particular fan of FreeBSD, and in some benchmarking I did between it
>>> and CentOS FreeBSD 7.x literally wiped the floor with the CentOS release I
>>> tried on IDENTICAL hardware.
>>> I also like the 3ware raid coprocessors - they work well, are fast, and I've
>>> had zero trouble with them.
>>>
>>> -- Karl
>>>
>>>
>>
>>
>> With CentOS 5.x, I have to do quite a bit of tuning to get it to perform
>> well.  I often get almost 2x the performance after tuning.
>>
>> For I/O --
>> Deadline scheduler + reasonably large block device read-ahead + XFS
>> configured with large 'allocsize' settings (8MB to 80MB) make a huge
>> difference.
>>
>> Furthermore, the 3ware 35xx and 36xx (I think) I tried performed
>> particularly badly out of the box without tuning on CentOS.
>>
>> So, Identical hardware or not, both have to be tuned well to really compare
>> anyway.
>>
>> However, I have certainly seen some inefficiencies with Linux and large use
>> of shared memory -- and I wouldn't be surprised if these problems don't
>> exist on FreeBSD or OpenSolaris.
>>
> I don't run the 3x series 3ware boards.  If I recall correctly they're not
> true coprocessor boards and rely on the host CPU.  Those are always going to
> be a lose compared to a true coprocessor with dedicated cache memory on the
> card.

I screwed up, it was the 95xx and 96xx that stink for me.  (Adaptec 2x as
fast, PERC 6 25% faster) with 1TB SATA drives.

Thought 96xx was a good chunk faster due to the faster interface.

>
> The 9xxx series boards are, and are extremely fast (make sure you install the
> battery backup or run on a UPS, set the appropriate flags, and take your
> chances - writeback caching makes a HUGE difference.)

Not at all in my experience, 12 drives in raid 10, and 300MB/sec sequential
trasfer rate = crap.  Heavily tweaked, 450MB/sec.  (Adaptec 5805 =
600MB/sec).

>
> Other than pinning shared memory on FreeBSD (and increasing a couple of
> boot-time tunables to permit large enough shared segments and semaphore lists)
> little is required to get excellent performance.
>
> The LSI cards that DELL, Intel and a few others have used (these appear to be
> deprecated now as it looks like LSI bought 3ware) also work well but their
> user interface is somewhat of a pain in the butt compared to 3Ware's.
>
> -- Karl
>

Claus Guttesen wrote:

However, I have certainly seen some inefficiencies with Linux and large use
of shared memory -- and I wouldn't be surprised if these problems don't
exist on FreeBSD or OpenSolaris.   

This came on the freebsd-performance-list a few days ago.

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=13001+0+current/freebsd-performance 

Geezus - that's a BIG improvement.

I have not yet benchmarked FreeBSD 8.x - my production systems are all on FreeBSD 7.x at present.  The improvement going there from 6.x was MASSIVE.  8.x is on my plate to start playing with in the next couple of months.

8.x, I will note, is NOT YET RELEASED, and you're playing with fire to run it in a production environment at the present time.  I've been a strong proponent (and user) of FreeBSD for years, going back to when I ran my ISP on it.  It has had its problems from time to time as do all operating systems, but when 8.X is released and is stable it will definitely be worth moving to - IF its stable.

I have systems with two years of uptime on them running FreeBSD 6.x in production use, and haven't had an actual OS crash on a production FreeBSD machine in a very long time.

One thing FreeBSD has focused more and more on is SMP efficiency and effective utilization of all the cores in the system. I have several systems running 8-way SMP (Quad Xeons) and a couple running the CoreQuadExtreme (4 physical cores w/2 threads each via HT) and get excellent performance out of all of them.  The key is to make sure your I/O subsystem is up to the job and split storage across spindles and controllers as necessary so you don't run into bottlenecks there.

-- Karl

Axel Rau wrote:
> Am 05.10.2009 um 19:42 schrieb Karl Denninger:
>
>> I have not yet benchmarked FreeBSD 8.x - my production systems are
>> all on FreeBSD 7.x at present.  The improvement going there from 6.x
>> was MASSIVE.  8.x is on my plate to start playing with in the next
>> couple of months.
> Did you ever try gjournal or zfs as tablespace?
>
gjournal, no.  ZFS has potential stability issues - I am VERY interested
in it when those are resolved.  It looks good on a test platform but I'm
unwilling to run it in production; there are both reports of crashes and
I have been able to crash it under some (admittedly rather extreme)
synthetic loads.

-- Karl

Am 05.10.2009 um 19:42 schrieb Karl Denninger:

> I have not yet benchmarked FreeBSD 8.x - my production systems are
> all on FreeBSD 7.x at present.  The improvement going there from 6.x
> was MASSIVE.  8.x is on my plate to start playing with in the next
> couple of months.
Did you ever try gjournal or zfs as tablespace?

Axel
---
axel.rau@chaos1.de  PGP-Key:29E99DD6  +49 151 2300 9283  computing @
chaos claudius

Scott Carey wrote:
>
> On 10/5/09 10:27 AM, "Karl Denninger" <karl@denninger.net> wrote:
>
>
>> I don't run the 3x series 3ware boards.  If I recall correctly they're not
>> true coprocessor boards and rely on the host CPU.  Those are always going to
>> be a lose compared to a true coprocessor with dedicated cache memory on the
>> card.
>>
> I screwed up, it was the 95xx and 96xx that stink for me.  (Adaptec 2x as
> fast, PERC 6 25% faster) with 1TB SATA drives.
>
> Thought 96xx was a good chunk faster due to the faster interface.
>
I'm running the 9650s in most of my "busier" machines.  Haven't tried a
PERC card yet - its on my list.  Most of my stuff is configured as RAID
1 although I have a couple of RAID 10 arrays in service; depending on
the data set and how it splits up I prefer to have more control of how
I/O is partitioned rather than let the controller pick through striping.

I don't think I have any of the 95xx stuff out in the wild at present;
it didn't do particularly well in my testing in terms of performance.

-- Karl

On Sun, 4 Oct 2009, Mark Mielke wrote:

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

There are two reasonable paths you'll find in the Open Source world, which
mirror the larger industry at large:

1) Branch a stable release rarely.  Sit on it for a while without changing
anything before release.  Backport only critical stuff (important bug
fixes) into the stable version once it's out there.  Support that version
for years.  Examples of this model include RedHat and PostgreSQL, albeit
with the latter having a much more regular release schedule than most
"long-term release" pieces of software.

2) Branch a stable release often.  Push it out the door with fairly recent
components.  Backport little, because a new release is coming out the door
soon enough anyway.  It's impossible for this model to backport as much as
(1), because they have so many more releases to handle, and there's no
pressure to do so because "upgrade to the latest release to fix" is
usually an options.  Examples of this model include the Linux kernel
proper and Ubuntu.

My personal belief is that (2) never leads to stable software, and that
for the complexity level of the projects I follow you're lucky you can get
a stable version of one piece of software if you focus on it about every
year.  Once every two years would be better, because as you correctly note
it takes about that long for many hardware drivers to go from cutting-edge
to old, and that would give less disruption to admins.

That is unfortunately both more aggressive than the "long-term release"
stable versions provided by RedHat and less than the hyper-aggressive
schedules you'll find in Ubuntu and Fedora.  It does happen to be very
close to the PostgreSQL stable release frequency though:

8.0 2005-01-19
8.1 2005-11-08
8.2 2006-12-05
8.3 2008-02-04
8.4 2009-07-01

RedHat does a commendable job of backporting way more stuff than anybody
else I'm aware of.  The SATA issues you mention are actually a worst-case
for their development model.  The big SATA switch-over with "Parallel PATA
merge" happened in 2.6.19.  My recollection is that this was such a mess
at first is basically forced RedHat to release RHEL5 with 2.6.18, as there
wasn't expected to be a stable ATA stack from the resulting chaos for a
few releases they could use; anecdotally, I didn't find Linux
re-stabilized until between 2.6.20 and 2.6.22, depending on your hardware.

I contrast this with Ubuntu, which I can't accept as a server because
nothing I run into *ever* gets backported.  I know they backport
something, because I see the changelogs, but never what I run into.  I
encounter a bug or two in ever new Ubuntu release that makes life
difficult for me, and in every case so far the "resolution" was "fixed in
<next letter>".  In two of those cases I recall I saw the same bug fix
(from an upstream package) was backported into RHEL.

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

With all due respect, this was operator error on your part.  Buying the
hardware and then guessing that everything will work out fine with the OS
install isn't ever a path to stable either.  I (and every other person who
deals regularly with RHEL on increasingly new hardware) could have told
you this was going to be a disaster, that you don't try to provision a
server using native SATA with unknown compatibility on that OS.  I don't
have this problem (for the database servers at work at least--suffered
through it plenty with random white boxes).  I buy from a vendor who
figures this out and old sells me stuff that works on RHEL.  You have a
larger process problem you can't blame on the software.

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

How exactly is this any different from "effective support" for the kernel
at large, which integrates way more patches than that between releases?
I see RedHat as having a much smaller set of patches to manage, which is
one reason their releases are more stable than "pick a random kernel
release".

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

On 10/5/09 11:15 AM, "Karl Denninger" <karl@denninger.net> wrote:

> Scott Carey wrote:
>>
>> On 10/5/09 10:27 AM, "Karl Denninger" <karl@denninger.net> wrote:
>>
>>
>>> I don't run the 3x series 3ware boards.  If I recall correctly they're not
>>> true coprocessor boards and rely on the host CPU.  Those are always going to
>>> be a lose compared to a true coprocessor with dedicated cache memory on the
>>> card.
>>>
>> I screwed up, it was the 95xx and 96xx that stink for me.  (Adaptec 2x as
>> fast, PERC 6 25% faster) with 1TB SATA drives.
>>
>> Thought 96xx was a good chunk faster due to the faster interface.
>>
> I'm running the 9650s in most of my "busier" machines.  Haven't tried a
> PERC card yet - its on my list.  Most of my stuff is configured as RAID
> 1 although I have a couple of RAID 10 arrays in service; depending on
> the data set and how it splits up I prefer to have more control of how
> I/O is partitioned rather than let the controller pick through striping.
>
> I don't think I have any of the 95xx stuff out in the wild at present;
> it didn't do particularly well in my testing in terms of performance.
>
> -- Karl
>
Let me make sure I clarify here --

The 3ware 9[56]xx issues I have seen were with throughput on larger RAID
array sizes -- 8+ disks total.  On smaller arrays, I have not tested.

Scott Carey wrote:

On 10/5/09 11:15 AM, "Karl Denninger" <karl@denninger.net> wrote:
 

I'm running the 9650s in most of my "busier" machines.  Haven't tried a
PERC card yet - its on my list.  Most of my stuff is configured as RAID
1 although I have a couple of RAID 10 arrays in service; depending on
the data set and how it splits up I prefer to have more control of how
I/O is partitioned rather than let the controller pick through striping.

I don't think I have any of the 95xx stuff out in the wild at present;
it didn't do particularly well in my testing in terms of performance.

-- Karl   

Let me make sure I clarify here --

The 3ware 9[56]xx issues I have seen were with throughput on larger RAID
array sizes -- 8+ disks total.  On smaller arrays, I have not tested.
 

Interesting... I'm curious if that's why I haven't run into it - I get damn close to N x rotational on sequential I/O out of these boards; you can't really do better than the physics allow :)

I'll have to play with some larger (> 8 unit) Raid 1 and Raid 10 arrays and compare to see if there's a "knee" point and whether its a function of the aggregation through the chipset or whether it's a card issue.  I suspect it's related to the aggregation as otherwise I'd have seen it on some of my larger configurations, but I tend to run multiple adapters for anything more than 8 spindles, which precludes the situation you've seen.

Of course if you NEED 12 spindles in one logical device for capacity reasons........

-- Karl

Claus Guttesen <kometen@gmail.com> wrote:

>
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=13001+0+current/freebsd-performance

Not being particularly passionate about any OS, I've been intrigued by
the FreeBSD benchmarks.  However, management is reluctant to use boxes
which don't have heavily-advertised decals on the front.  At the
moment they're going with IBM X-series boxes, and FreeBSD isn't
supported, so we'd be on our own.  Has anyone had any experience with
this combination?  (In particular, our biggest machines are x3850 M2
boxes.)

Oh, and of course I dispute the supremacy of vim as an editor -- why
use that when you've got "ed"?  ;-)

-Kevin

Am 05.10.2009 um 20:06 schrieb Karl Denninger:

> gjournal, no.  ZFS has potential stability issues - I am VERY
> interested
> in it when those are resolved.  It looks good on a test platform but
> I'm
> unwilling to run it in production; there are both reports of crashes
> and
> I have been able to crash it under some (admittedly rather extreme)
> synthetic loads.
How do you prevent from long running fsck with TB size ufs partitions?
I had some hope for zfs13 and fbsd 8.0.

Axel
---
axel.rau@chaos1.de  PGP-Key:29E99DD6  +49 151 2300 9283  computing @
chaos claudius

> Claus Guttesen <kometen@gmail.com> wrote:
>
> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=13001+0+current/freebsd-performance
>
> Not being particularly passionate about any OS, I've been intrigued by
> the FreeBSD benchmarks.  However, management is reluctant to use boxes
> which don't have heavily-advertised decals on the front.  At the
> moment they're going with IBM X-series boxes, and FreeBSD isn't
> supported, so we'd be on our own.  Has anyone had any experience with
> this combination?  (In particular, our biggest machines are x3850 M2
> boxes.)

You can download a live-cd and see if it recognizes disk-controller,
nic etc. on HP bce and bge, em GB nics works fine.

> Oh, and of course I dispute the supremacy of vim as an editor -- why
> use that when you've got "ed"?  ;-)

I have tried edlin on dos 3 or something like that. But don't recall
the commands! :-)

--
regards
Claus

When lenity and cruelty play for a kingdom,
the gentler gamester is the soonest winner.

Shakespeare

Axel Rau wrote:
>
> Am 05.10.2009 um 20:06 schrieb Karl Denninger:
>
>> gjournal, no.  ZFS has potential stability issues - I am VERY interested
>> in it when those are resolved.  It looks good on a test platform but I'm
>> unwilling to run it in production; there are both reports of crashes and
>> I have been able to crash it under some (admittedly rather extreme)
>> synthetic loads.
> How do you prevent from long running fsck with TB size ufs partitions?
> I had some hope for zfs13 and fbsd 8.0.
>
> Axel
Turn on softupdates.  Fsck is deferred and the system comes up almost
instantly even with TB-sized partitions; the fsck then cleans up the cruft.

-- Karl

On Mon, Oct 5, 2009 at 6:35 AM, Adam Tauno Williams
<awilliam@opengroupware.us> wrote:
>> Maybe - if the only thing the server is running is PostgreSQL. Show of
>> hands - how many users who ONLY install PostgreSQL, and use a bare
>> minimum OS install, choosing to not run any other software? Now, how
>> many people ALSO run things like PHP, and require software more
>> up-to-date than 3 years?
>
> Me.
>
> Not everyone is running LA?P stack applications.

Me too, even though we are running LAPP stack.  Not all LAPP stacks
are small intranet servers with a few hundred users.  We service 1.5
Million users running 10k to 20k page views a minute.  On a server
farm that fills 2/3 of a cabinet.

Am 05.10.2009 um 23:44 schrieb Karl Denninger:

> Axel Rau wrote:
>>
>> Am 05.10.2009 um 20:06 schrieb Karl Denninger:
>>
>>> gjournal, no.  ZFS has potential stability issues - I am VERY
>>> interested
>>> in it when those are resolved.  It looks good on a test platform
>>> but I'm
>>> unwilling to run it in production; there are both reports of
>>> crashes and
>>> I have been able to crash it under some (admittedly rather extreme)
>>> synthetic loads.
>> How do you prevent from long running fsck with TB size ufs
>> partitions?
>> I had some hope for zfs13 and fbsd 8.0.
>>
>> Axel
> Turn on softupdates.  Fsck is deferred and the system comes up almost
> instantly even with TB-sized partitions; the fsck then cleans up the
> cruft.
Last time, I checked, there was a issue with background-fsck.
I will give it a chance with my new 8.0 box.
Do you have any experience with SSDs w/o BBUed Raidcontroller?
Are they fast enough to ensure flash write out of drive cache at power
failure after fsync ack?

Axel
---
axel.rau@chaos1.de  PGP-Key:29E99DD6  +49 151 2300 9283  computing @
chaos claudius

Axel Rau wrote:
>
> Am 05.10.2009 um 23:44 schrieb Karl Denninger:
>
>> Turn on softupdates.  Fsck is deferred and the system comes up almost
>> instantly even with TB-sized partitions; the fsck then cleans up the
>> cruft.
> Last time, I checked, there was a issue with background-fsck.
> I will give it a chance with my new 8.0 box.
> Do you have any experience with SSDs w/o BBUed Raidcontroller?
> Are they fast enough to ensure flash write out of drive cache at power
> failure after fsync ack?
>
> Axel
> ---
> axel.rau@chaos1.de  PGP-Key:29E99DD6  +49 151 2300 9283  computing @
> chaos claudius
IMHO use the right tools for the job.  In a DBMS environment where data
integrity is "the deal" this means a BBU'd RAID adapter.

SSDs have their own set of issues, at least at present..... For data
that is read-only (or nearly-so) and of size where it can fit on a SSD
they can provide VERY significant performance benefits, in that there is
no seek or latency delay.  However, any write-significant application is
IMHO still better-suited to rotating media at present.  This will change
I'm sure, but it is what it is as of this point in time.

I have yet to run into a problem with background-fsck on a
softupdate-set filesystem.  In theory there is a potential issue with
drives that make their own decision on write-reordering; in practice on
a DBMS system you run with a BBU'd RAID controller and as such the
controller and system UPS should prevent this from being an issue.

One of the potential issues that needs to be kept in mind with any
critical application is that disks that have "intelligence" may choose
to re-order writes.  This can bring trouble (data corruption) in any
application where a drive claims to have committed a block to stable
storage where in fact it only has it in its buffer RAM and has not
written it to a platter yet.  The only reasonable solution to this
problem is to run backed-up power so as to mitigate the risk of power
disappearing at an inopportune time.  Backed-up power brings other
advantages as well (as a quality UPS usually comes with significant
filtering and power conditioning) which refuses the up front risk of
failures and is thus IMHO mandatory for any system that carries data you
care about.

-- Karl

On Tue, 6 Oct 2009, Karl Denninger wrote:

> Axel Rau wrote:
>>
>> Am 05.10.2009 um 23:44 schrieb Karl Denninger:
>>
>>> Turn on softupdates.  Fsck is deferred and the system comes up almost
>>> instantly even with TB-sized partitions; the fsck then cleans up the
>>> cruft.
>> Last time, I checked, there was a issue with background-fsck.
>> I will give it a chance with my new 8.0 box.
>> Do you have any experience with SSDs w/o BBUed Raidcontroller?
>> Are they fast enough to ensure flash write out of drive cache at power
>> failure after fsync ack?
>>
>> Axel
>> ---
>> axel.rau@chaos1.de  PGP-Key:29E99DD6  +49 151 2300 9283  computing @
>> chaos claudius
> IMHO use the right tools for the job.  In a DBMS environment where data
> integrity is "the deal" this means a BBU'd RAID adapter.
>
> SSDs have their own set of issues, at least at present..... For data
> that is read-only (or nearly-so) and of size where it can fit on a SSD
> they can provide VERY significant performance benefits, in that there is
> no seek or latency delay.  However, any write-significant application is
> IMHO still better-suited to rotating media at present.  This will change
> I'm sure, but it is what it is as of this point in time.

this depends on what SSD you use. for most of them you are correct, but
there are some that have very good write performance.

David Lang

On Mon, 5 Oct 2009, Jean-Michel Pouré wrote:
> Go for Debian:
> * It is a free community, very active.
> * It is guaranteed to be upgradable.
> * Very easy to administrate via apt-get.

http://www.debian.org/News/2009/20091007

If you like Debian, but want to use FreeBSD, now you can have both.

> Choose Debian SID or testing, which will provide the latest fixes.

I disagree. If you want a stable server, choose Debian stable, which was
last released in February. It gets all the relevant fixes, just like any
other supported stable distribution - just no new major versions of
software. The next stable release is scheduled for the new year.

If you want the latest and greatest, then you can use Debian testing.

Matthew

--
 The surest protection against temptation is cowardice.
                                              -- Mark Twain

Le jeudi 08 octobre 2009 15:40:53, Matthew Wakeling a écrit :
> On Mon, 5 Oct 2009, Jean-Michel Pouré wrote:
> > Go for Debian:
> > * It is a free community, very active.
> > * It is guaranteed to be upgradable.
> > * Very easy to administrate via apt-get.
>
> http://www.debian.org/News/2009/20091007
>
> If you like Debian, but want to use FreeBSD, now you can have both.
>
> > Choose Debian SID or testing, which will provide the latest fixes.
>
> I disagree. If you want a stable server, choose Debian stable, which was
> last released in February. It gets all the relevant fixes, just like any
> other supported stable distribution - just no new major versions of
> software. The next stable release is scheduled for the new year.
>
> If you want the latest and greatest, then you can use Debian testing.

testing and sid are usually the same with a 15 days delay.

I strongly suggets to have a debian lenny and to backport newer packages if
really required (like postgres 8.4). Debian come with good tools to achieve
that (and there is debian-backport repository, sure)


--
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org

Cédric Villemain <cedric.villemain@dalibo.com> writes:
>> If you want the latest and greatest, then you can use Debian testing.
>
> testing and sid are usually the same with a 15 days delay.

And receive no out-of-band security updates, so you keep the holes for
3 days when lucky, and 10 to 15 days otherwise, when choosing
testing. So consider stable first, and if you like to be in danger every
time you dist-upgrade while *having* to do it each and every day, sid is
for your production servers.

> I strongly suggets to have a debian lenny and to backport newer packages if
> really required (like postgres 8.4). Debian come with good tools to achieve
> that (and there is debian-backport repository, sure)

stable + backports + volatile (when it makes sense) is a perfect choice :)
--
dim