Thnak you for answer.

We can NOT use X86_64 due to application NOT support 64 bits.

If I take some RAM out of server (for example take out 32 GB RAM and left 32 GB RAM on server), will problem fix?

Thanks.

--- 10/11/24 (三)，John R Pierce pierce@hogranch.com 寫道：

寄件者: John R Pierce pierce@hogranch.com 主旨: Re: [CentOS] CENTOS 5.5 X86 continue get "out of memory" error????? 收件者: "CentOS mailing list" centos@centos.org 副本: "mcclnx mcc" mcclnx@yahoo.com.tw 日期: 2010年11月24日,三,下午7:13 On 11/24/10 3:59 PM, mcclnx mcc wrote:

...

we just installed CENTOS 5.5 X86 (32 bits) on DELL

server.  After installed we also apply lated O.S. patches.

...

This server have 64 GB RAM and run

"2.6.18-194.26.1.el5PAE #1 SMP ".  when I doing "cp", "mv". "ftp", ....  it continue "kill" my process and pop up "out of memory" on /var/log/messages:

...

...

any one know why?

Is CENTOS X86 5..5 really NOT stable version?

no, using 32 bit PAE with 64GB of memory means your page tables are using ALL of the available 1GB kernel address space available. the 32 bit kernel chokes itself under these extreme conditions.   this is an architectural feature of the Intel x86, the "solution" is 64 bit mode where the page tables and kernel and a user process don't all have to fit into 4GB of address space.

On 25 November 2010 00:23, mcclnx mcc mcclnx@yahoo.com.tw wrote:

We can NOT use X86_64 due to application NOT support 64 bits.

Unless you can't use virtualisation, you can run any 32 bit app on 64 bit platform provided that you have the 32 bit dependencies installed. The other way around is not possible. if you are compiling it from source, 32 bit and 64 bit libraries install in separate directories and thus you can point to the correct path in any configure script. I regularly compile Apache & PHP for 32 bit on CentOS, thanks to 32 bit binary modules only available on that platform.

On Wed, Nov 24, 2010 at 07:39:05PM -0500, Robert Heller wrote:

At Thu, 25 Nov 2010 08:23:10 +0800 (CST) CentOS mailing list centos@centos.org wrote:

...

Thnak you for answer.

We can NOT use X86_64 due to application NOT support 64 bits.

You can run 32-bit applications with a 64-bit kernel. CentOS / RHEL installs the 32-bit shared libraries along with the 64-bit libraries.

You can also install xen (or kvm) and run 32-bit slave (virtual) processes, with reasonable amounts of memory.

Also if you want to go for custom "hacks"..

Install 32bit CentOS 5, and then manually install 64bit kernel. So all the userspace is 32bit, only the kernel is 64bit.

This allows you to use all the memory without problems.

You might have problems with some tools that need to talk to the kernel.. iptables, open-iscsi, etc..

-- Pasi

...

If I take some RAM out of server (for example take out 32 GB RAM and left 32 GB RAM on server), will problem fix?

Thanks.

--- 10/11/24 (侉)John R Pierce pierce@hogranch.com 寫道

...

寄件者: John R Pierce pierce@hogranch.com 䞻旚: Re: [CentOS] CENTOS 5.5 X86 continue get "out of memory" error????? 收件者: "CentOS mailing list" centos@centos.org 副本: "mcclnx mcc" mcclnx@yahoo.com.tw 日期: 2010幎11月24日,侉,䞋午7:13 On 11/24/10 3:59 PM, mcclnx mcc wrote:

...

we just installed CENTOS 5.5 X86 (32 bits) on DELL

server.  After installed we also apply lated O.S. patches.

...

This server have 64 GB RAM and run

"2.6.18-194.26.1.el5PAE #1 SMP ".  when I doing "cp", "mv". "ftp", ....  it continue "kill" my process and pop up "out of memory" on /var/log/messages:

...

...

any one know why?

Is CENTOS X86 5..5 really NOT stable version?

no, using 32 bit PAE with 64GB of memory means your page tables are using ALL of the available 1GB kernel address space available. the 32 bit kernel chokes itself under these extreme conditions.   this is an architectural feature of the Intel x86, the "solution" is 64 bit mode where the page tables and kernel and a user process don't all have to fit into 4GB of address space.

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

-- Robert Heller -- 978-544-6933 / heller@deepsoft.com Deepwoods Software -- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

On 11/24/2010 6:23 PM, mcclnx mcc wrote:

Thnak you for answer.

We can NOT use X86_64 due to application NOT support 64 bits.

Have you tested this? The X86_64 kernel will run 32 bit processes without any problem and a normal Centos install will include most of the 32-bit libraries you are likely to need. If you have errors at startup, fixing them should be a matter of noting which libraries are missing and installing them (which yum will do for you if you add the .i386 specifier to the package name. The system is designed to handle running 32 and 64 bit apps concurrently and it would be unusual for it not to work.

On Wed, Nov 24, 2010 at 7:27 PM, mcclnx mcc mcclnx@yahoo.com.tw wrote:

Thank you for answer.

This server used to run under CENTOS 3.9 X86 and No problem.  Due to application can not use CENTOS 3.9 we need upgrade to CENTOS 4 or 5.

If I re-install it and use CENTOS 4.8 X86, will problem gone or not?

No, problem will remain.

At Thu, 25 Nov 2010 21:38:42 +0800 (CST) CentOS mailing list centos@centos.org 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).

Do you know for sure that the application cannot run as a 32-bit application under a 64-bit kernel? Have you tested it? Nobody is suggesting that you re-compile for 64-bits and you don't need to.

Note: a 32-bit application process can only access 4gig max (this is its address space limit). You realize that any given *32-bit* process [tree] can never access more than 1/16th of the 64gig of physical RAM. Even if your application is multi-threaded, the total combined address space of a 32-bit multi-threaded process tree is 4gig (the threads share the same address space). If you are running multiple *independent* processes, that yes you can use more memory, but no more than 4gig per 32-bit process [tree]. Do you understand what this means? Do you understand that running a 32-bit OS on a machine with 64gig of physical RAM is pretty much meaningless, and as you have discovered does not work well.

The PAE kernel only really works properly upto 16gig. You can switch to the hugemem kernel and take a performance hit.

Your options:

1) pull 48gig of ram out of the machine and go from there. With the PAE kernel you can't really use that 'extra' 48gig of RAM anyway (as you have discovered).

2) switch to the hugemem kernel and accept the performance hit (this is probably a lose-lose option). There is no real advantage to do this.

3) install the 64-bit kernel but continue to use 32-bit user space application code. This really should work. Have you even tried this? Eg on a test system. It really is not going to cost much to get a 'little' 64-bit desktop machine and install the x86_64 system and see what happens when you run your application.

4) install xen with a 64-bit kernel dom0 and install one (or more) 32-bit domUs (with reasonable amounts of RAM (eg 4gig) and run your application in the 32-bit domUs. Your application should not know the difference -- it will see a 32-bit environment. Have you even tried this, Eg on a test system (see above).

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

CentOS 3 uses a 2.4 kernel, which is different from the 2.6 kernels in CentOS 4 and 5. I'm guessing you *probably* had installed the hugemem kernel, which would have 'worked' (as in not caused the problems you are seeing). It is also possible that the 2.4 kernel simply did not 'see' the 64gig of RAM or something like that (kernel bug or kernel limitation).

--- 10/11/24 (三)，Kwan Lowe kwan.lowe@gmail.com 寫道：

...

寄件者: Kwan Lowe kwan.lowe@gmail.com 主旨: Re: [CentOS] CENTOS 5.5 X86 continue get "out of memory" error????? 收件者: "CentOS mailing list" centos@centos.org 日期: 2010年11月24日,三,下午7:31 On Wed, Nov 24, 2010 at 7:27 PM, mcclnx mcc mcclnx@yahoo.com.tw wrote:

...

Thank you for answer.

This server used to run under CENTOS 3.9 X86 and No

problem. 痃ue to application can not use CENTOS 3.9 we need upgrade to CENTOS 4 or 5.

...

If I re-install it and use CENTOS 4.8 X86, will

problem gone or not?

No, problem will remain. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

On Nov 24, 2010, at 6:27 PM, mcclnx mcc wrote:

Thank you for answer.

This server used to run under CENTOS 3.9 X86 and No problem. Due to application can not use CENTOS 3.9 we need upgrade to CENTOS 4 or 5.

If I re-install it and use CENTOS 4.8 X86, will problem gone or not?

A few options.

You might test the program on a 64 bit OS. The 64 bit version of CentOS should be able to run many 32 bit programs. It would depend on dependencies in the program whether it would have issues or not. In fact, other changes since 3.9 may be more of an issue than the 64 bitness of the OS.

It is possible to limit the amount of RAM that the OS will recognize by passing options to the kernel in grub.

You also may be able to run a 32 bit version of the OS in virtualization under a 64 bit OS, leaving the rest of the RAM available for the main system. 2 computers in 1.

On 11/24/10 11:06 PM, cpolish@surewest.net wrote:

http://www.centos.org/docs/4/html/release-notes/as-x86/ Red Hat Enterprise Linux 4 includes a kernel known as the hugemem kernel. This kernel supports a 4GB per-process user space (versus 3GB for the other kernels), and a 4GB direct kernel space. Using this kernel allows Red Hat Enterprise Linux to run on systems with up to 64GB of main memory. The hugemem kernel is required in order to use all the memory in system configurations containing more than 16GB of memory. The hugemem kernel can also benefit configurations running with less memory (if running an application that could benefit from the larger per-process user space, for example.)

that kernel will also greatly increase overhead of all system calls as they will require pagetable swaps on every transition from user -> kernel and back, and any arguments to kernel calls will have to be copied to a static shared buffer (and results copied back). large arguments will be particularlly ugly.