Question & Answer
Question
Cause
Answer
To change the memory model in WebSphere Application Server, go to the Admin Console -> Application Servers -> $SERVER -> Java and Process Management -> Process Definition -> Environment Entries
- Click New. Name: LDR_CNTRL Value: MAXDATA=0XB0000000@DSA
- Click OK
- Click New. Name: IBM_JVM_LDR_CNTRL_NEW_VALUE Value: MAXDATA=0XB0000000@DSA
- Click OK
- Save, synchronize, and restart
IBM_JVM_LDR_CNTRL_NEW_VALUE is not strictly required but should be set to alleviate potential confusion.
There are two ways to determine the size of the shared libraries' code and data:
- using svmon and
- using a system dump and dbx. Both of these methods can also help determine native memory segment usage.
Method #1: Using svmon
This method assumes a recent version of the JVM, and that LDR_CNTRL has not been explicitly set, and that -Xmx is less than 2304MB. In this case, the JVM will have automatically chosen MAXDATA=0XA0000000@DSA in which shared library code are in segment 0xD and shared library data are in segment 0xF (see http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/topic/...... aix_mem_32_default.html and More Links at the bottom).
Execute the following command to gather a snapshot of virtual address space segment usage (you may need root access): svmon -rmP $PID
Find the rows with the Esid column value of 'd' or 'f'. Note the PSize column for each ('s', 'm') and map this to the PageSize at the top of the svmon output (4KB, 64KB, respectively). For both segments, on the next line with "Addr Range: X..Y," calculate (Y+1)*PageSize.
Method #2: Using a system dump and dbx
Ensure that "Enable full CORE dump" and ulimits are properly set (see http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/topic/....aix_setup_full_core.html). This is often done by editing /etc/security/limits and adding stanzas for the user that runs WebSphere, setting core=-1, nofiles=-1, data=-1, and fsize=-1, and restarting the JVMs.
Gather a system dump using the non-destructive "gencore $PID $CORE_NAME" command or the destructive "kill -6 $PID" or "kill -11 $PID" commands.
If you will be analyzing the core on the same machine with dbx, then find the full path to the Java executable for that PID (for example, using "ps -elf | grep $PID" and taking the first part of the CMD column), and execute the command "dbx $JAVA_EXE_PATH $CORE_PATH". Ensure that there are no errors or warnings starting dbx (such as "warning: The core file is not a fullcore"). Run the command "coremap" (you may also pipe the output to a file using "coremap > coremap.txt" then quitting using "quit" and analyzing the output file normally). For each "Mapping: Loaded Module Text" and "Mapping: Loaded Module Data" line, take the size value from that line, convert from hexadecimal into decimal, and sum the values. This may be less precise than svmon.
If you will be analyzing the core on a different machine, run jextract on the core which will package all the libraries along with the core: <WAS>/java/jre/bin/jextract $CORE_PATH. This will produce a .zip file. Extract the .zip file on the target machine, and run dbx as above, passing the Java executable in the ZIP along with the option -p /usr=./usr:/opt=./opt... to account for the location of the libraries in the ZIP.
Note: The other effect of changing to the 0xB@DSA memory model is that segment 0xE is no longer available for mmap/shmat, but instead those allocations grow down in the same way as the Java heap. If your -Xmx is a multiple of 256MB (1 segment), and your process uses mmap/shmat (for example, client files), then you will have one less segment for native memory. This is because native memory allocations (malloc) cannot share segments with mmap/shmat (Java heap, client files, etc.). To fully maximize this last segment for native memory, you can calculate the maximum amount of memory that is mmapped/shmatted at any one time using svmon (find mmapped sources other than the Java heap), and then subtract this amount from -Xmx. -Xmx is not required to be a multiple of 256MB, and making room available in the final segment may allow the mmapped/shmatted allocations to be shared with the final segment of the Java heap, leaving the next segment for native memory.
More Links:
https://www.ibm.com/developerworks/java/library/j-nativememory-aix/
http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/topic/......aix_auto_ldr_cntrl.html
http://publib.boulder.ibm.com/infocenter........._1vg000121410cbe-1195c23a635-7ffa_1001.html
http://publib.boulder.ibm.com/infocenter/javasdk/.....aix_ldr_cntrl_page_sizes.html
http://publib.boulder.ibm.com/infocenter/aix/v6r1/.......svmon.htm
Was this topic helpful?
Document Information
Modified date:
03 October 2022
UID
swg21450144