Common Incorrect beliefs about process address limits on 32bit platforms

Preface

Most people believe that one cannot go beyond 1.2g-1.7g or so as a maximum heapsize for Java servlet based applications deployed with 9iAS/10gAS. The ignorant would cite this as a limitation of 32bit Intel architecture.

In reality, this assumption is only partially true as it applies only to SMP Kernels and that too with the default -unlimited native stack size per process. People might say "Your results may vary" but the truth is that there are several factors like process address space & stack limits, kernel limits, shared memory support etc which need to be understood to make an educated comment on the question of  - What is the best limit I can push the JVM heap to for my application and How can I do it  without compromising stability ?.

Kernel Limitations and known issues of JDK1.4 Heaps on 32-bit platform vis-a-vis 64-bit platforms

While it is generally believed that the maximum memory addressable space for a process on 32-bit platforms is 1.7g , this is only true for the SMP kernel.

Right? Well, only if unlimited(usually the default, given by $ ulimit -s command ) native stack size is used. If any lesser value like 10m, 8m, 6m, 4, 2m are used, the user address space increases to 2.7g.

There are white papers on metalink having details how the SGA (implemented as OS shared memory area) of an oracle database on 32-bit platform can be pushed to 3.5g. This is achieved by lowering the starting address point in the memory address stack for the oracle executable and relinking it, so that the memory addressable space increases, when a process from the oracle executable is spawned.

For JVMs, the application specific golden limit has really to be found out by trial and error by tweaking ulimit -s and some other factors.

The easy command for finding the maximum heapsize limit can be found by raising the value of -Xmx and -Xms switches at jvm startup:

# e.g. if you want to see if a heap of 1400m can be allocated and committed at startup

$ java -version -Xmx1400m -Xms1400m 

If this doesnt fail and you get the version of java in the output, keep pushing the OS with higher heap sizes and see when the segmentation fault Signal 11 errors start coming. You have reached the forbidden limit and would do well to keep ~300-400m off this limit for accomodating native stack space for java threads. The native stack space requiement would vary as per concurrent user load of the application.

The golden memory rule:


The golden rule of thumb for max address space per process to be kept in mind is:


(Total size of managed heap + native heap) + (number of threads X thread stack size) = max process address space allowed by Kernel


Viewing it in a more wholistic way,


Data segment (=Total size of managed heap + native heap) + stack segment(= # of threads X thread stack size) = max user address space allowed by Kernel

More possibilities with JDK1.5

There are some exciting things which can be done using JDK1.5, like addressing 3G & more of heapsize & using LargePages feature, using which its possible to eliminate heavy swapping, iowait & Garbage collection, since the heap is kept in real memory.

It should be noted that JDK1.5 is only supported at this time with Oracle Applications 11.5.10. Its not yet certified yet with 11.5.9 mostly due to logistical reasons and for avoiding regression testing efforts with JDK1.6, which Oracle plans supposedly plans on doing.

Related Links and Articles

Case study: How to leverage LargePages option of J2SE1.5 on Linux hugemem kernel for 11i Oracle Apps

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

bocadmin_ww

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today