64bit or 32bit linux for 4gb ram server?
 

Hello,

the virtual server with 4Gb ram, in future will be upgraded to more ram.
Is it better to use 64bit CentOS or 32bit?

I listen 64 takes more memory..

Thank you

for a server
servers host many sites

there is NO choice 32 bit is incapable of handling traffic

64 bit os's have been used for the last 12 years or more

use 64 bit

64-bit RAM usage is usually only 20-30% higher than 32-bit usage. This is not a reason to use 32-bit. RAM is relatively cheap so just buy some more if you have problems.

Probably it will make very little difference. In the unlikely event that it does make a significant difference, probably 64-bit will be better.

If you use only 64 bit applications on a 64-bit OS, that consumes a little more ram than using only 32-bit applications on a 32-bit OS.

If you mix 32-bit and 64-bit applications on a 64-bit OS, that takes a larger amount of extra ram compared to only 32-bit applications on a 32-bit OS.

But either way we are talking about a pretty trivial fraction of 4GB. Other decisions you make will be more important in conserving ram if you even have any need to conserve ram.

The word "server" can mean a wide range of things and within each a wide range of possible load. On a system with just 4GB of ram it may be conceivable, but is quite unlikely that a server running a 32-bit OS would be unable to handle the amount of traffic, while a server running a 64-bit OS would be able.

I don't disagree with that overall advice, just with the idea that there are powerful reasons behind that conclusion.

Maybe a 32-bit OS would make the server a little faster and able to handle a little more load than with a 64-bit OS. Maybe the other way around. Most likely very little difference.

That is very misleading. It depends enormously on the use of the system. Executable code is typically bigger in 64-bit and maybe by 20%-30%. But executable code is typically a small fraction of total ram use on a system with 4GB or more of ram. Certain less common kinds of data are 100% bigger in 64-bit applications compared to 32-bit. But text and graphics and sound and numeric data and most other kinds are all exactly the same size in 64-bit as 32-bit. If your ram is 90% consumed by typical data that is the same size, then your overall ram use can only be a few % different between 32-bit and 64-bit. That is the common case for a 4GB server. A significant difference in ram use is an uncommon case.

Thx, please why no one mentioned 32bit OS can handle only less than 4GB memory? Or is it not truth?
"Yes, a 32-bit architecture is limited to addressing a maximum of 4 gigabytes of memory."
Source: http://stackoverflow.com/a/8869596

??

With 4 GB you would still need PAE to use all 4 GB in 32-bit. PAE is a hack to get around the 32-bit addressing restriction.

I think 20-30% more RAM is a reasonable estimate based upon my tests. It is certainly more accurate than people out there saying 64-bit programs use twice as much RAM as 32-bit. I agree that it varies and can be less or more than my estimate. I've never seen any 64-bit program use twice the RAM of 32-bit. I have seen programs use almost the same amount of RAM in 32-bit and 64-bit.

Undoubtedly, the CPU and motherboard is 64-bit. Therefore, a 64-bit OS should be used.

It depends what you mean by "memory", but for practical purposes it is just not true.

A 32-bit OS limits each process to 3GB of address space. It does not limit the system to 4GB of ram.

A server likely runs many different processes and it also has caching and other ram needs outside the address space of any one process. So the limit of 3GB address space per process usually makes no difference.

What kind of "server" are we talking about? Exactly what service software will be running? There are some "service" programs that concentrate almost everything into a single process. Even with almost everything in one process, there is enough ram use outside that process that a system with just 4GB of ram is likely OK with the 3GB limit per process. But you said there would be more ram added later. If almost everything is in a single service process, a system with 6GB of ram would not be OK with the 3GB limit per process.

Most "service" software does not put almost everything into a single process. They run multiple processes sharing the code and dividing the work and the data. In that case, the 3GB limit per process probably does no harm even on a system with 16GB of ram.

PAE is not a "hack" and it is not a way around 32-bit addressing.

All addressing on X86 Linux systems (32 bit or 64 bit OS's and with or without PAE) goes through page mapping. Every address, whether in a user process or in the kernel, is translated from "virtual" to "logical" by that mechanism.

The virtual addresses used within a 32-bit program are inherently 32-bit. There is no (hack or otherwise) way around that. The virtual addresses used within a 64-bit program are inherently 64-bit.

The translation mechanism, that converts virtual address to logical address, contains no fundamental assumption that a virtual address and a logical address are the same size. In non PAE 32-bit, a logical address happens to be 32-bits. In PAE 32-bit, a logical address happens to be 36-bits. In 64-bit OS mode, logical address sizes are larger than 36-bits and smaller than 64-bit. Their exact size varies among models of 64-bit CPU. Barely any kernel code needs to be concerned with the size of a logical address and no user code needs to care.

The 32-PAE page translation data structures are very similar (in detail) to the 64-bit page translation data structures. The 64-bit are just a tiny amount more complicated and have a tiny amount more overhead.

The 32-bit non PAE page translation data structures are similar in concept and basic mechanism to the above two, but differ from the above two in much more of the details than the above two differ from each other.

There are frequent statements in this forum that imply some page translation is necessary with PAE and not necessary without PAE. That is nonsense. The same basic page translation is always there: 32-bit non-PAE, 32-bit PAE, or 64-bit. It is all fundamentally the same. In a tiny implementation detail, 32-bit PAE is more similar to 64-bit than it is to non-PAE 32-bit.

Why restrict yourself to 32-bit?

Sure the system right now might only have 4 GB of RAM, and might not be running any processes right now that use more than 3 GB of RAM, but are you positive that's never going to change? With a 64-bit OS, just add more RAM and you're good to go. With a 32-bit OS, you might have to re-install the entire OS if the usage of the system changes for whatever reason a few years down the road.

I doubt you'd ever notice one or the other if you tested 1000 systems. You can easily set up one and then set up the other and run some tests to see. It would be system dependent as to the best. All parts of your system may either help or hurt this result.

There is very little to be gained either way.

If we knew use, load, hardware, apps and such we might be able to guess better but the only way to tell would be a live test.

Almost all distro's either offer PAE standard or have it as an option.

You can use x32 ABI on a 64-bit system if you are worried about resources. http://en.wikipedia.org/wiki/X32_ABI

I repeat ... you should use an operating system that is correct for the native architecture of whatever chip you have.

Otherwise, you would be forcing a 64-bit native chip to run in "32-bit compatibility mode." Which is roughly equivalent to forcing a car to emulate a bicycle.

Don't let the facts stand in the way of powerful analogy.

I have to say it kinda cracks me up when I'm not dismayed by all the misinformation about 64bit Linux vs/ 32bit w/PAE. Not one person has asked exactly what will this server be doing. If, for example, it is a game server that must also handle Wine games, I contend that 32bit version is considerably better... at the very least substantially easier to build, configure, and maintain. PAE can handle up to 64GB of ram. The only reason people get hung up on this 4GB "limitation" is because of Windows XP and it's 4GB limitation which is strictly a licensing restriction and choice. It is best to use the right tool for a given job so it depends entirely on what job(s) this server will be asked to perform. For some, 64bit is undeniably better, but the reverse is also true.

I thought I asked that in post # 8. But we haven't heard from the OP since then.

I never tried any games in wine, so maybe I'm missing something. But wine support for win32 is easy (and default) when you install wine on a 64-bit Linux.

In theory. But in practice it doesn't work up to 64GB because the limit on kernel virtual address space becomes unmanageable. Long ago (RHEL 4) there was a really ugly kludge used in addition to PAE to fix the kernel virtual address space limit and really support 64GB physical ram. But that kludge was clearly inferior to using a 64-bit kernel on any 64-bit capable CPU. I don't know if that is even still a kernel build option. No distribution still supports it (in their distributed kernels).

The OP was talking 4GB now, and some more later. So PAE should cover it and theory about whether PAE is OK for over 16GB is not relevant.

Mainly licensing, but: Windows has a less modular interface between drivers and kernel, which made it harder to adapt many drivers to work with 32-bit systems over 4GB. Linux driver problems with PAE were fixed early and thoroughly. Many Windows drivers were never fixed. So in addition to a special license for 32-bit Windows supporting over 3 and fraction GB of ram, you also are very restricted in devices because so many drivers won't work.

Especially with code compiled by GCC or by current versions of other compilers, I think it is quite hard to find the situation in which it is significantly better to use a 32-bit kernel on a 64-bit system with 4GB or more of ram. (An obsolete version of the Intel C/C++ compiler was dramatically better than current 32-bit x86 compilers, and using that eliminated one of the fundamental advantages of 64-bit, letting the other advantages of 32-bit sometimes matter more).

Sure you can find lots of situations in which choosing a 32-bit kernel would make the server a trivial amount faster. But finding a case where 32-bit is significantly faster is difficult.

Cases where 64-bit is significantly faster than 32-bit are also somewhat rare. But they are not terribly rare. It is a real possibility to consider when making the choice.