- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - Linux
- >
- RH 5.5 32 bit and number / size of java engines.
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-24-2011 11:51 AM
тАО02-24-2011 11:51 AM
Also, if anyone has experience in this, how far "up" in memory can I run 32 bit java engines? Can I keep making 32 java engines and putting them out in memory all the way to 48GB total memory?
Reason I'm concerned is that I don't want to just assume this is all feasible and suddenly hit an "oh, it doesn't do that past xxxx" number for that type of application... after spending all kinds of time and $$$ planning on a particular layout to work. I'm worried about something goofy like we had/have with HPUX and "memory windows" to make things work, or worse not have it workable beyond some limit at all.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-24-2011 09:37 PM
тАО02-24-2011 09:37 PM
Re: RH 5.5 32 bit and number / size of java engines.
With PAE enabled you can address upto 64 Gb theoretically. But the application need to be PAE aware ( I know only theoretical side of it ). In windows you have a smilar concept called Address Windowing Extensions. On a nix box, you might have to make use of mmap() to map regions into a file. You can possibly get help from more experienced members on this issue.
--Lucifer
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-25-2011 12:51 AM
тАО02-25-2011 12:51 AM
Re: RH 5.5 32 bit and number / size of java engines.
To answer the original question, yes you can keep creating additional 32-bit Java engines until you run out of memory (physical and swap). Each will get its own private 32-bit address space.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-25-2011 01:04 AM
тАО02-25-2011 01:04 AM
SolutionFirst, in Linux, the 32-bit memory address space limitation is still in effect: no process can see more than 4 GB of address space. However, it doesn't have to be the _same_ 4 GB for all processes: each process can see different parts of the larger memory space. (Linux and Windows use PAE in very different ways.)
Second, there's a kernel configuration option called "vmsplit". It dictates how much of the 4 GB address space is reserved for kernel use. Typically, in modern distributions configured for PAE, the vmsplit is set to 3GB/1GB: 3 GB for the user process, 1 GB for the kernel. (You can change this by compiling a custom kernel, if you have special requirements.)
The kernel-reserved 1 GB will always stay mapped in the processor's address space, because it includes page tables (essential for memory management), memory-mapped hardware control registers and kernel-userspace API. So, typically the lowest 1 GB of system memory will be known as "low memory": the rest will be "high memory".
If your hardware includes IOMMU, it can do I/O operations directly to high memory. But many systems with 64-bit-capable Intel processors don't have an IOMMU: these must rely on SWIOTLB, also known as "bounce buffers". When a disk controller needs to deliver some data to a process that does not happen to be in the 32-bit addressable 4 GB memory space at the moment, the data must be passed into a "bounce buffer" located in the low memory, and transferred from there to its ultimate destination when the target process is mapped into the address space again. This causes some overhead in I/O operations.
This also means the low memory becomes a critical resource: it is possible to run out of low memory while still having plenty of high memory free. This is one of the reasons why RedHat recommends using a real 64-bit system instead of PAE whenever possible: RedHat won't even provide support for 32-bit PAE systems with more than 16 GB of memory on RHEL 6, although running such a system may still be technically possible.
Together, the vmsplit and the address space limit work like this: with a 48 GB system, you could run about 15 Java processes of 3 GB each... but even if you had 40 GB of memory free, you could not run even a single process sized 3.1 GB or more.
Please remember that 64-bit x86_64 Linux systems can run 32-bit software just fine.
My opinion: PAE is useful if you need to go only slightly above the 32-bit 4 GB limit, maybe even up to 16 GB or so. But for a 48 GB system, 64-bit OS is clearly a better choice.
Having said that, I currently have some production systems that are running 32-bit with PAE and have about 48 GB of memory... but the corresponding development systems are already 64-bit, and the testing + production will migrate to 64-bit with the next major upgrade.
MK
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-25-2011 01:15 AM
тАО02-25-2011 01:15 AM
Re: RH 5.5 32 bit and number / size of java engines.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-28-2011 06:11 AM
тАО02-28-2011 06:11 AM
Re: RH 5.5 32 bit and number / size of java engines.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-27-2011 11:48 AM
тАО03-27-2011 11:48 AM
Re: RH 5.5 32 bit and number / size of java engines.
ulimit -s 8192
It will allow you to get closer to the 4GB limit of the java heap of your JVMs.
Regars.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-28-2011 03:33 PM
тАО03-28-2011 03:33 PM
Re: RH 5.5 32 bit and number / size of java engines.
As to how many JVMs you can run - it depends on your RAM.
We've since moved our apps to 64bit JVMs (JRE) as the 32 bit JVM simply does not cut it any more.
And as Matti has so eloquently explained - RHEL 64bit OS can run 32 bit apps just fine. We have dropped 32 bit installations of RHEL in our continuing Linux adventure - in fact our fledgling "migration/porting environment" - I've reently installed Intel's C Compiler suite that can build/compile both 32 and 64 bit binaries.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-31-2011 06:02 AM
тАО03-31-2011 06:02 AM
Re: RH 5.5 32 bit and number / size of java engines.
From I read, only 32 bit apps are supported for Oracle Applications - so are you successfully using 64 bit java engines for Oracle ERP applications?
Thank you!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-31-2011 06:26 AM
тАО03-31-2011 06:26 AM