[CentOS] CENTOS 5.5 X86 continue get "out of memory" error?????

Thu Nov 25 18:52:11 UTC 2010
John R Pierce <pierce at hogranch.com>

On 11/25/10 5:38 AM, mcclnx mcc wrote:
> Anyway to make it work on CENTOS 4.8 X86?
>
> We don'y want use X86_64 or Virtulation due to application issue (DB).
>

32 bit database servers run just fine on a 64 bit kernel.   In fact, 
they run better on a 64 bit kernel than they do on a 32 bit kernel, due 
to being able to use somewhat larger shared memory buffers, and much 
larger OS disk cache.     Of course, a 64bit database server would be 
even better, as it would be able to use a much larger shared memory, 
creating significantly better performance.

I hate to ask what database doesn't come in a 64bit flavor in 2010.  
Certainly, all the major ones do (oracle, db2, informix, mysql, postgresql)

> how come we been run CENTOS 3.9 X86 on this server for few years and NO problem?

RHEL 3 and 4 supported the 'hugemem' kernel.  EL 5 doesn't.   Ok, some 
explanations may be in order...

a 32bit x86 machine can only directly address 4GB of virtual memory 
address space.   each process in a 32bit linux environment has its own 
4GB virtual address space.   The kernel uses the top 1GB of the virtual 
space, this is shared by all processes, and the application process gets 
up to the remaining 3GB to itself.    to map these virtual addresses 
into physical addresses, the x86 CPU uses 'page tables' in main memory, 
in Linux, these all have to fit in that 1GB kernel space.

the standard x86 32bit architecture also only supports 4GB of PHYSICAL 
memory, however the PAE extensions allowed more physical memory at the 
expense of much larger page tables.   when you go past 16GB physical 
memory, the page tables become really large and use all of the kernel 
address space, leaving no room for other kernel stuff (like disk IO 
buffers).

now, EL 3 and EL 4 supported an unusual configuration known as HUGEMEM.  
in HUGEMEM, the kernel is no longer the top 1GB of each processes 4GB 
address space, instead, the kernel runs in its OWN 4GB address space 
(and hence can no longer directly address the current process, this 
causes all sorts of complicated performance issues), but now it has room 
for larger page tables.

This HUGEMEM support was very complex and problematic, especially for 
kernel drivers, so it was dropped in EL 5 since 64bit support doesn't 
have ANY of these issues (the kernel can use as many gigabytes as it 
needs and still fit into all processes address space which is now 
theoretically petabytes), and in 64 bit, the page table structures were 
redesigned to better support large memory without wasting so much room 
themselves.