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
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
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
On Thu, Oct 1, 2009 at 3:34 PM, Jean-David Beyer <jeandavid8@verizon.net> wrote:
I do not know the others, and doubt it makes much difference.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
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
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
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
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
On Thu, Oct 1, 2009 at 3:44 PM, Jean-David Beyer <jeandavid8@verizon.net> wrote:
Matthew Wakeling wrote:The main difference between those is that Fedora tries to be the latest andFor starters, FreeBSD isn't Linux at all. Secondly, the other three options you have listed are all Red Hat versions - not much variety there.
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 have no trouble with Red Hat Enterprise Linux or its equivalent, CentOS.
I know that some people swear by Red Hat, but I personally have had nothing but trouble from such installations,
However the following point is valid:The theory with the Red Hat Enterprise Linux distribution is that you runespecially when trying to upgrade to a newer version of Postgres.
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.--^^-^^ 06:05:01 up 15:04, 4 users, load average: 6.01, 5.69, 5.33
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/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. -- 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.
"Many of lifes failure are people who did not realize how close they were to success when they gave up."
-Thomas Edison
And its not 200 differnet server , its only single pg8.3 handling 200+ dbs.
Arvind S
"Many of lifes failure are people who did not realize how close they were to success when they gave up."
-Thomas Edison
On Thu, Oct 1, 2009 at 8:26 PM, Haszlakiewicz, Eric <EHASZLA@transunion.com> wrote:
>-----Original Message-----I'm running Postgres on NetBSD and RHEL4. I haven't noticed any particular differences in Postgres performance due to the OS, but then again I haven't performed any kind of formal benchmarks, nor am I really stressing the database all that much (most of the time).
>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.
My preference for OS to run is NetBSD, because I'm most familiar with it and there have been some fairly significant recent focus on performance improvements. If you're really worried about getting the best performance I think you're just going 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 different servers sounds like it might be problematic on any OS due to the amount of shared memory that'll need to be allocated.
eric
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
Attachment
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.
Attachment
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 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
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
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 also like the 3ware raid coprocessors - they work well, are fast, and I've had zero trouble with them.
-- Karl
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).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.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 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
Attachment
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
Attachment
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
Attachment
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
Attachment
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:
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
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.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. -- KarlWith 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.
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
Attachment
> 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:
Geezus - that's a BIG improvement.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
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
Attachment
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
Attachment
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
Attachment
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:
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
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 :)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. -- KarlLet 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.
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
Attachment
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
Attachment
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
Attachment
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
Attachment
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.
The other thing to take into consideration is the number of vendors who release drivers for linux distros. Typically, RHEL and SLES get the quickest release of drivers for things like network cards, storage cards, etc...
--Scott
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
Attachment
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