Re: New server to improve performance on our large and busy DB - advice? (v2)

On Fri, Jan 15, 2010 at 11:28 AM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> Tom Lane wrote:
>>
>> Given the Linux kernel hackers' apparent disinterest in fixing their
>> OOM kill policy or making write barriers work well (or at all, with
>> LVM), I think arguing that Linux is the best database platform requires
>> a certain amount of suspension of disbelief.
>>
>
> Don't forget the general hostility toward how the database allocates shared
> memory on that list too.
>
> I was suggesting Linux as being the best in the context of consistently
> having up to date packages that install easily if you can use the PGDG yum
> repo, since that was a specific request.  The idea that Linux is somehow the
> preferred platform from PostgreSQL is pretty weird; it's just a popular one,
> and has plenty of drawbacks.
>
> I think it's certainly the case that you have to enter into using PostgreSQL
> with Linux with the understanding that you only use the most basic and well
> understood parts of the OS.  Filesystem other than ext3?  Probably buggy,
> may get corrupted.  Using the latest write-barrier code rather than the most
> basic fsync approach?  Probably buggy, may get corrupted.  Using LVM instead
> of simple partitions?  Probably going to perform badly, maybe buggy and get
> corrupted too.  Assuming software RAID can replace a hardware solution with
> a battery-backed write cache?  Never happen.
>
> There's a narrow Linux setup for PostgreSQL that works well for a lot of
> people, but some days it does feel like that's in spite of the priorities of
> the people working on the Linux kernel.

As someone who uses Linux to run postgresql dbs, I tend to agree.
It's not quite alchemy or anything, but there are very real caveats to
be aware of when using linux as the OS for postgresql to run on top
of. I will say that XFS seems to be a very stable file system, and we
use it for some of our databases with no problems at all. But most of
our stuff sits on ext3 because it's stable and reliable and fast
enough.

Each OS has some warts when it comes to running pg on it. Could be a
narrower selection of hardware drivers, buggy locale support, iffy
kernel behaviour when lots of memory is allocated. And most have a
way to work around those issues as long as you're careful what you're
doing. If you're familiar with one OS and its warts, you're more
likely to be bitten by the warts of another OS that's new to you no
matter how good it is.

And as always, test the crap outta your setup, cause the time to find
problems is before you put a machine into production.