| 3:34 am on Dec 7, 2011 (gmt 0)|
Not much point in putting in ( and paying for ) 16 gigs of RAM if the 32 bit OS can't talk with all of it :)
32 bit is going to be able to see and talk with, a little short of 4 gigs..
IIWY I'd get 64 bit system set up from the start.."clean" install is always better than "upgrade"..
[edited by: Leosghost at 3:40 am (utc) on Dec 7, 2011]
| 3:39 am on Dec 7, 2011 (gmt 0)|
|Does 64 bit really matter than much? |
It does if you want to actually use all that RAM
|Or what about if I started off with 32 bit, then did an upgrade of the OS, is that likely to work? |
Waste of time.
Either do it or don't.
I've been running RHE 64-bit for a few years now, worked fine first time out of the box.
Never looked back.
| 3:43 am on Dec 7, 2011 (gmt 0)|
@wheel..what flavour are you on now in 32 ..and what flavour are you looking at in 64 ?
| 9:27 am on Dec 7, 2011 (gmt 0)|
64 bit compiled applications use more memory than their 32 bit versions, mainly because code and data structures are aligned in blocks of 8 bytes rather than 4 bytes. Expect an average increase of your application footprint around 20%. So if you need 1GB for a running application on a 32 bit box, expect the same application with the same load to use around 1.25GB on a 64 bit platform.
Furthermore a number of applications are more buggy on 64 bit than on 32 bit, although they seem to work. This is often caused by long/int conversions because these type definitions on C/C++ changed slightly between the two platforms. One such a problem child I have found is the ntpd time server which produces false statistics on 64 bit in a number of distributions.
Some applications are not able to share data between 32 and 64 bit. AWStats data files collected on 32 bit Linux can't be moved to a 64 bit Linux machine for example.
But having said that, 64 bits gives you a lot of extra memory space if you have installed the RAM and it provides a growth path to the future. I am currently running three 32 bit Linux servers and two 64 bit servers and planning to upgrade them all to 64 bit in the near future.
| 10:22 am on Dec 7, 2011 (gmt 0)|
Another way of looking at it is endure the pain now, or at a later time. Move to 64bit was done some time back. There's a reason why it is called the bleeding edge of technology.
| 10:40 am on Dec 7, 2011 (gmt 0)|
When I moved to 64 bit a couple of years ago I ran a few tests to see which was faster.
32-bit passed all tests as the fastests but obviously there is the 4Gb limit - which is going to be useless if you are running a meaty DB.
You want the O/S and apps to use the RAM for caching, buffers and stuff. Thus for any rig with > 4Gb you are better off with 64-bit.
One alternative is 32-bit in PAE mode. This allows 32-bit to break the 4Gb barrier. But there is a slight performance hit with this.
As the others have said you are better off doing a fresh install with 64-bit version.
One gotcha with Centos 64-bit is that you can get into a mess with it installing some 32-bit apps and some 64-bit. In yum.conf put
exclude = *.i?86
right at the start, before you do any further yum install / yum updates
| 3:09 am on Feb 15, 2012 (gmt 0)|
Yes, with 16gb of memory, the 32-bit linux os is not utilizing any but 3gb of it.
| 10:35 am on Apr 4, 2012 (gmt 0)|
@apachewebserverguy Only if you have done nothing to enable it to do so. Google PAE.
| 10:37 am on Apr 4, 2012 (gmt 0)|
As far as I'm concerned, there's no issue with going 64 bit. Linux has been 64 bit friendly almost since the get-go. I have had absolutely no issues running 64 bit for the last 6+ years.
| 10:44 am on Apr 4, 2012 (gmt 0)|
Welcome here on WebmasterWorld zaktoo and thanks for your insights. With 6+ years of experience, you are certainly one of the early users of 64 bit Linux and have a wealth of experience.