Re: Upgrade RHEL3 x86_64 to RHEL4 x86?

[Tom Sightler <ttsig tuxyturvy com>]

On Sun, 2005-10-30 at 01:10 +0200, Terje Bless wrote:
> Tom Sightler <ttsig tuxyturvy com> wrote:
> 
> >Just because I'm curious, why did you do this anyway?  I understand that
> >the box doesn't NEED it, but it can take advantage of it, and it's the
> >same price so why not run the distro that takes full advantage of the
> >capabilities?
> 
> Because I, perhaps erroneously, have assumed that the 64bit version introduces a
> not insignificant overhead, and because I observe many problems reported on
> mailinglists — often with maintaining 32bit compatibility in userspace — that
> suggest the 64bit version isn't worth the extra hassle unless I actually need to
> address more memory than this application currently needs.

Well, I must admit that userspace compatibility was a little issue for
us too, so this is probably a valid concern that has caused us a small
amount of grief but, once we understood it a little it really hasn't
been that bad.  Our biggest issue was with a java applet that just
refused to run on the new jre versions and the old jre's wouldn't run
except in a 32-bit shell.

> Then again, the box (Dell PE1850) is an EM64T whose only claim to 64bit'ed-ness,
> as far as I know, is an ability to take somewhere in excess of 8GB RAM.
> Otherwise it's a fundamentally 32bit system, and probably — I'm not particularly
> well versed at CPU tech, or the finer detail of system architecture — register
> starved to boot, so the last thing you want is to bog it down dealing with 64bit
> addressing.

Well, I'm sure it's still register starved, but I do know that EM64T
provides 16 General Purpose Registers and 16 XMM registers, which is
twice as many as 32-bit only CPU's but these go to waste if you don't
run 64-bit code.

> >We've got several applications that see significant performance
> >improvement running on the 64-bit version rather than the 32-bit
> >version.

We deployed our Dell 1850's (and one 2850) late last year and I may not
have the specific numbers anymore (I'll look at the office on Monday it
might be on an archive CD) but basically we installed RHEL3 on the
systems and installed our applications which were based on
Apache/Java/MySQL.  The systems only had 2GB of RAM so they weren't
loaded with memory at the time.  We ran three sets of benchmarks, one
with 32-bit apps on 32-bit OS, 32-bit apps on 64-bit OS, and 64-bit
(well, as much as we could make it) on 64-bit OS.

Overall, performance was great with all of the solutions, but we saw a
small percentage gain even running the 32-bit apps on the 64-bit OS, and
about a 20% increase when we tested with 64-bit everything (well, except
java which we had to leave as 32-bit).  Most of the difference seemed to
happen in MySQL, and there are other MySQL benchmarks that show
significant performance improvements on 64-bit Linux. 

The main reason we decided to deploy with 64-bit was because we didn't
know how quickly demand would grow and, based on our performance numbers
we thought memory would be a bigger limitation than CPU.  As it turns
out that was a good bet because now, less than a full year later, these
systems have already been expanded to 12GB of RAM and scaled well to
handle the load.  

> Am I really going to have to reinstall the box /again/ this weekend? :-)

Well, there are certainly advantages and disadvantage to both
approaches.  We recently installed 32-bit Windows on a Dell 2850 only to
regret it after our application turned out to be a much bigger memory
hog than anticipated.

Probably the only way to be sure is to benchmark your applications and
see how they do.  Your probably correct that, if your applications
aren't memory hogs, you won't see major differences, and if you have
plenty of CPU anyway then it may not be worth the extra hassle.  I think
only you can answer that question.  We've been quite happy with our
choice, but it may be more trouble than it's worth for you.  I certainly
think you brought up valid issues, which is why I asked.

Later,
Tom