FreeBSD 5.4 or 6 for DB server with 9500S-4 ?

[ray at redshift.com]

| > My policy is to never be the first kid on the block to test something new -
| > especially not in production.  FreeBSD 5.4 has been hammered on for a long time
| > and works really well.  5.4 is an evolution of 5.2.1 and 5.3 - all of which are
| > very mature and very stable.  I've been running FreeBSD in production since
| > version 5.2.1 and have been using FreeBSD since 4.9 (previously we used Redhat
| > linux for our production servers).  Anyway, when I build a machine, here is
| > exactly what I use:
| > 
| 
| I disagree. First-off, 6.0-RELEASE may be new to the block, but 6.0 has been 
| kicking it almost as long as 5.4-RELEASE has been out. Most of the experiences 
| I've heard back from other users are saying 6.0, even RC-1 before -RELEASE 
| actually runs better than 5.4-RELEASE. Certain key optimizations in 6.0 will 
| help you out, (eg filesystem changes, SMP support, hardware drivers, etc). 
| Considering the newer hardware you've chosen (dual core amd64 cpu) - 6.0 is much 
| better prepared to handle it in the kernel. I've been running 6.0-RC1 on one of 
| the dual opterons we have here now for a couple of months now - performance is 
| great and havn't had a moments downtime yet. Seriously, do not discount 6.0 
| because it's a '.0' release, really it's not. As Ray pointed out, 5.4 was an 
| evolution of 5.2 - 5.3, etc... what he did not potentially realize, is that 6.0 
| is of that same evolution. Read the notes as to why the version skipped from 5.4 
| -> 6.0, and you'll realize that 6.0 was simply a new version number to a release 
| that would have otherwise been say 5.5, the reason for the skip was because of 
| the large number of new capbilities and features. And yes, new features generall 
| can equal new bugs - but if you're not relying upon them and you're doing the 
| same thing you would with a 5.4 machine, then why sacrafice the added filesystem 
| performance and hardware support by not running 6.0?

Can you provide some specific benchmarks you have run comparing 5.4 to 6.0?
I've heard too many people, too many times, pull stats out of the air regarding
"the new release".  If you have done some specific testing to show that 5.4 is
slow than 6.0 - then great.  But if you are just going by the seat of your
pants, then I think it can be dangerous to assume a new version if faster.  In
the case of FreeBSD 6.0, it may very well be the case, but I personally have no
tested it in production.  In cases of things like PHP5 vs. PHP4, 4 is clearly
faster.  Same for apache.  2.0.52, based on my testing, is clearly slower
compared to 1.3.33.  If you have stats showing the different between 5.x and 6.x
in areas such as disk I/O, CPU load, etc., I for one would appreciate seeing
some hard numbers.  So far, I haven't had a chance to run any and I'm certainly
interested in version 6.0  However, as a system admin for close to 25 years, I
still stick by my guns that immediately jumping to the latest release for use in
a production machine can be quite risky.  If you are just playing around at
home, that's one thing.  But if 5x9+ uptime is critical, then it's a whole
different story.
 
| I agree, short of large security patches, stick with a -RELEASE code. In any 
| given production environment stability is key. While cvsup'ing and building the 
| new box everyday to stay current sounds good - it is in practice not good for 
| production servers - if it isn't broke, don't fix it.

Agreed.  CVS is great for getting the latest code to test, but I've seen friend
constantly doing CVS's and build worlds on servers in production only to have
them exhibit strange behavior until the next patch comes out.  In fact, not too
long ago a buddy of mine updated a machine and ended up having to roll back the
OS to a previous version in order to cure some strange crashing problem (which
later went away a few patches down the road).  
 
| 	As Olaf pointed out many times in this thread (or related threads) - budget is 
| key with this deal, so I doubt load balancing and plopping another machine in is 
| an option his client really wants to hear about - until they've gotten to a 
| point to justify doing so. Why scare customers away telling them they can buy 
| more, if you just sold them something new why isn't it going to be good enough - 
| guarantee that's not a question you'll want to provoke.

I haven't seen Olaf's P/L for the year, so I can't really comment.  All I can
say is some people build clusters some don't :)  For those that do, load
balancing is a much more viable option in a lot of cases than trying to squeeze
every last ounce of performance from a machine.  I've been woken up too many
times between 1995 and 1999 with machines dead to the world because we tried to
tweak every last red cent out of them (running Linux) to do it any more.  As far
as my opinion on it, in the long run, it's money ahead if you have redundancy,
even if the initial jump into it is a little more costly than you want.

| Same response. Look at the SMP file, it's basically "options smp; include 
| GENERIC"... just copy the GENERIC to your own config, remove the driver(s) you 
| don't require, add 'options SMP' and any other options you may wish - rename the 
| config and go from there.

When I first moved from i386 to AMD64, that one tripped me up but good! :)  I
was so used to just editing GENERIC, I didn't even look at SMP or realize it was
there for about 3 days.
 
| The ports collection has been optimized for 'the average install', leveraging 
| performance for functionality in most situations to be ideal. The ports usually 
| have added patches or adjustments to code which integrates them better with 
| FreeBSD, if you're not all that familair with the code you're working with, (in 
| this case mysql), then I'd reccomend you stick with the ports collection.
| 	However, that being said - note that the ports collection isn't always up to 
| date, and you may want a differing version of mysql. Follow the documentation on 
| mysql.com and you should be just fine - fairly staght forward install and 
| differs little from doing so via the FreeBSD ports collection. In any production 
| system though, I highly reccomend compiling from source vs downloading binaries 
| - that way nothing has been linked to/from librairies which may or may not be 
| the same on your system.

Agreed.
 
| I agree, stick with 4.1.x, but for different reasons. Compatability; not sure 
| what you are doing, the size or scope of the database you're dealing with, but 
| if for example you're going to be writting and app in windows which uses the 
| myodbc driver to connect... then you may run into problems with newer versions 
| of mysql. I encountered a LOT of this, when we moved from 3.x up to 4.1, largely 
| because of changes in the client - at least I was aware of that before I 
| started, but I did have to rebuild client librairies on all webservers, and 
| re-install odbc drivers on client machines throughout the building because of 
| it. Might not be something you're willing/ready to undertake for the features 
| you've already mentioned not being required in mysql 5.

Couldn't comment on using the Win API to connect directly to MySQL, but it
doesn't sound fun! :)  Are you using VC++ to do it or MFC or ?  If you have any
sample code for that, I'd be interested in seeing it (off list).  

Anyway, hopefully Olaf doesn't hang himself over there after reading our
messages.  I think he's on a pretty good track to a nice server from what I've
read so far.  I still am not a fan of jumping to the latest 'anything' as far as
production machines go.  Yes, it may work, but I've been burned too many times
in the past doing that.  If it's not a production environment, then that's a
totally different story, but for anything business related or HA, it's usually a
risk to be the first ones running something fresh off hacking-room-floor :)

Anyway, have a good weekend.

Ray