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

[Nathan Vidican]

ray at redshift.com wrote:
> | > 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.
>

Again, my point was that 6.0-RELEASE is not the 'newest/latest untested 
release', but rather that it comes as a new version number to a large number of 
improvements over the 5.4 branch. While I have no 'cold hard numbers' to support 
my benchmarking, I will say from experience running 6.0 in production now for a 
few months (actually have a production server environment running 6.0-RC1, 
because on the AMD64 platform it proved to be more stable and more complete than 
5.4-RELEASE did). I had many issues with various libraries in FreeBSD 5.4, 
especially in areas of ldap client, threads, and a port of nss_ldap. All of 
which is based on the same code I've been running for a LONG time on other 
machines now. Without digressing too far from the subject, the bottom line was 
6.0 did (and still does) run cleaner, and faster without the stability issues I 
encountered with 5.4 on AMD64 platform - and as I said in my original reply I 
disagree because 6.0 is not as new as you claim. Generally, I share the same 
opinion as yourself - don't jump to something new just because it's new, stick 
with what's tried-and-true. That being said, I still stand to my original remark 
when I say with some confidence that 6.0 - IS tried-and-true, and I can back 
that up with at least the last 4 months of day-to-day production use of it.


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

Yeah, caught me too - didn't even realize one could do an include-xyz from a 
kernel config file. Guess that's how one learns though eh ;)

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

Actually, just work with MS ADO as you normally would, it's just a connection 
string. Essentially no different in code from that to using MS Access or SQL 
server connections, you simply supply a connection string (email off list if 
you'd like a sample).

> 
> 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 :)
> 

Again, 6.0 is NOT as new as you keep trying to stress it. Read the archives 
regarding why the release numbering jumped from 5.4 -> 6.0; and try asking those 
who have been running 6 for > 5-6months now without issue. In my case, I had 
issues with stability and librairies in 5.4 that forced me to prematurely move 
over to 6.0 - a step I did not take lightly with terabytes of data and a lot of 
users on the line. I did the research, talked to people running 6, and did as 
you suggested 'posting a thread for 5.4 vs 6.0 in production', check the list 
archives if you missed it.

> Anyway, have a good weekend.
> 
> Ray
> 
> 

I'm not trying to provoke you here, and I'm glad for the debate - but sometimes 
I tend to come off as though I'm trying to fight or argue... that's my bad, and 
just want to make sure you don't feel like I'm attacking/defending against you. 
I'd wish you a good weekend too, except that it's Monday now and I'm just 
getting back to reading my email ;)

> 


-- 
Nathan Vidican
nvidican at wmptl.com
Windsor Match Plate & Tool Ltd.
http://www.wmptl.com/