Date: Mon, 28 Nov 2005 08:58:04 -0500 From: Nathan Vidican <nvidican@wmptl.com> To: ray@redshift.com Cc: amd64@freebsd.org Subject: Re: FreeBSD 5.4 or 6 for DB server with 9500S-4 ? Message-ID: <438B0CEC.4070308@wmptl.com> In-Reply-To: <3.0.1.32.20051125121159.00a5d2f8@pop.redshift.com> References: <3.0.1.32.20051125041044.00a47720@pop.redshift.com> <3.0.1.32.20051121055411.00aa1490@pop.redshift.com> <20051119200222.V2029@roble.com> <20051119120051.39BE216A41F@hub.freebsd.org> <20051119200222.V2029@roble.com> <3.0.1.32.20051121055411.00aa1490@pop.redshift.com> <3.0.1.32.20051125041044.00a47720@pop.redshift.com> <3.0.1.32.20051125121159.00a5d2f8@pop.redshift.com>
next in thread | previous in thread | raw e-mail | index | archive | help
ray@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@wmptl.com Windsor Match Plate & Tool Ltd. http://www.wmptl.com/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?438B0CEC.4070308>