In [1], we have shown a case of performance tuning by sizing JRockit's Thread Local Area (TLA). For both test runs—TLA default and TLA tuned, they have been given the same heap size (i.e, 2g). However, in the conclusion, I have said:
Better performance is achieved by reducing pause time % in GC andTotal CPU % at the expense of total memory footprint (-1.6%).
In this article, we will clarify what the following phrase:
at the expense of total memory footprint (-1.6%)
means.
Java Heap vs Native Memory
> ./jrcmd 26413 print_memusage >JR_print_memusage.txt
>cat JR_print_memusage.txt
26413: Total mapped 4897980KB (reserved=1384484KB) - Java heap 2097152KB (reserved=0KB) - GC tables 70156KB - Thread stacks 48324KB (#threads=141) - Compiled code 1048576KB (used=41160KB) - Internal 1480KB - OS 401856KB - Other 760932KB - Classblocks 27136KB (malloced=26821KB #58548) - Java class data 441344KB (malloced=439083KB #271063 in 58548 classes) - Native memory tracking 1024KB (malloced=242KB #10)
Native Memory
Internal JVM memory management is, to a large extent, kept off the Java heap and allocated natively in the operating system, through system calls like malloc. This non-heap system memory allocated by the JVM is referred to as native memory.
For JRockit, you can constraint the amount of memory allocated to the Java heap, but not the native memory, in a Java process.[3] As shown above, process 26413 has been allocated 4897980KB (i.e., VSZ) in the virtual address space. However, this VSZ value is not very useful. What counts is the one reported by Resident Set Size (RSS; or physically resident memory). To find out the RSS of a Java process, you can do:
>ps -o pid,uid,state,rss,vsz,minflt,majflt,args -p 26413 >ps_26413.tmp
>cat ps_26413.tmp
PID UID S RSS VSZ MINFLT MAJFLT COMMAND 26413 60000 S 3295216 4889792 15194852 1 /scratch/user1/JVMs/jdk-jr/bin/java ...
For the process 26413, its total memory footprint (or RSS) is 3295216 KB and this is the KPI we have quoted in our benchmark comparison.
No comments:
Post a Comment