Analysis on high memory usage of Java processes

First, let's take a look at the jmap output of the next java process:

The code is as follows:

Copy code

[Lex @ chou ~] USD jmap-heap 837 Attaching to process ID 837, please wait... Debugger attached successfully. Server compiler detected. JVM version is 20.10-b01 Using thread-local object allocation. Parallel GC with 2 thread (s) Heap Configuration: MinHeapFreeRatio = 40 MaxHeapFreeRatio = 70 MaxHeapSize = 4294967296 (4096.0 MB) NewSize = 1310720 (1.25 MB) MaxNewSize = 17592186044415 MB OldSize = 5439488 (5.1875 MB) NewRatio = 2 Required vorratio = 8 PermSize = 21757952 (20.75 MB) MaxPermSize = 85983232 (82.0 MB) Heap Usage: PS Young Generation Eden Space: Capacity = 41025536 (39.125 MB) Used = 18413552 (17.560531616210938 MB) Free = 22611984 (21.564468383789062 MB) 44.883147900858624% used From Space: Capacity = 4325376 (4.125 MB) Used = 3702784 (3.53125 MB) Free = 622592 (0.59375 MB) 85.60606060606061% used To Space: Capacity = 4521984 (4.3125 MB) Used = 0 (0.0 MB) Free = 4521984 (4.3125 MB) 0.0% used PS Old Generation Capacity = 539820032 (514.8125 MB) Used = 108786168 (103.74657440185547 MB) Free = 431033864 (411.06592559814453 MB) 20.152302906758376% used PS Perm Generation Capacity = 85983232 (82.0 MB) Used = 60770232 (57.95500946044922 MB) Free = 25213000 (24.04499053955078 MB) 70.67684080542588% used and then use ps to look at it: [Lex @ chou ~] $ Ps-p 837-o vsz, rss VSZ RSS 7794992 3047320

I will not elaborate on the several generation online materials here. Here, we can calculate the sum and we can see that the former has allocated a total of 64 4 MB of memory to the Java environment, ps output VSZ and RSS are 7.4G and 2.9G respectively. What is the problem?
In the previous jmap output content, MaxHeapSize is configured on the command line,-Xmx4096m, the maximum heap memory that this java program can use.
VSZ refers to the allocated linear space, which is usually not equal to the actual memory size used by the program. There are many possibilities for this, such as memory ING and shared dynamic libraries, or if you apply for more Heap data from the system, the linear space will be expanded. You can run the pmap command to check the memory ing of a process:

The code is as follows:

Copy code

[Lex @ chou ~] $ Pmap-x 837 837: java Address Kbytes RSS Dirty Mode Mapping 0000000040000000 36 4 0 r-x -- java 0000000040108000 8 8 8 rwx -- java 201710000418c9000 13676 13676 13676 rwx -- [anon] 00000006fae00000 83968 83968 83968 rwx -- [anon] 0000000700000000 527168 451636 451636 rwx -- [anon] 00000007202d0000 127040 0 0 ----- [anon] ... ... 20177f55ee124000 4 4 0 r-xs-az.png 20177fff017ff000 4 4 0 r-x -- [anon] Ffffffffff600000 4 0 0 r-x -- [anon] ---------------------------------- Total kB 7796020 3037264 3023928

Here we can see a lot of anon, which indicates that the memory is allocated by mmap.

RSZ is the Resident Set Size, Resident memory Size, that is, the physical memory occupied by the process. In this example, RSZ and the actual heap memory usage are less than 2.3 GB, the GB memory is composed of the following:

1. The memory required by the JVM itself, including the third-party libraries it loads and the memory allocated by these libraries
2. The DirectBuffer of NIO is the allocated native memory.
3. Memory ing files, including some JAR and third-party libraries loaded by JVM, and used in the program. Some static files in the above pmap output are not in the heap of Java. Therefore, as a Web server, remove the static files from the Web server, put it in nginx or CDN.
4. JIT and JVM will compile the Class into native code, and the memory will not be small. If Spring AOP is used, CGLIB will generate more classes, the memory overhead of JIT will also increase, and the GC of JVM of the Class itself will put it in Perm Generation, which is difficult to recycle. In this case, the JVM should be allowed to use ConcurrentMarkSweep GC, and related GC parameters should be enabled to allow the unused class to be removed from Perm Generation. Parameter configuration:-XX: + UseConcMarkSweepGC-X: + CMSPermGenSweepingEnabled-X: + CMSClassUnloadingEnabled
5. JNI: some native libraries called by JNI interfaces also allocate some memory. If The JNI library memory leaks, you can use memory leakage tools such as valgrind to detect
6. Thread stack. Each thread has its own stack space. If there are more threads, this overhead will be obvious.
7. For jmap/jstack sampling, frequent sampling will also increase memory usage. If you have server health monitoring, remember that this frequency should not be too high. Otherwise, health monitoring will become a disease-caused monitoring.
Jstat can be used to monitor the GC heap and GC of JVM. For example, the monitoring process refresh every 837 milliseconds and outputs 20 times:

The code is as follows:	Copy code
[Lex @ chou ~] $ Jstat-gcutil 837 1000 20 S0 S1 E O P YGC YGCT FGC FGCT GCT 0.00 80.43 24.62 87.44 98.29 7101 119.652 19.719 139.371 0.00 80.43 33.14 87.44 98.29 7101 119.652 19.719 139.371

The meanings of the fields are as follows:

Percentage of the first surviving vor in the S0 young generation used in the current capacity
Percentage of used vor in the second surviving zone of S1 young generation in the current capacity
E percentage of Eden used in the young generation (Eden) in current capacity
O old generation used percentage of current capacity
Percentage of used P perm generation to current capacity
Number of gc times in the young generation from application startup to sampling
Time spent by gc in the young generation from application startup to sampling (s)
Number of gc times of the old generation (full gc) from application startup to sampling
The time (s) taken by the old generation (full gc) gc from application startup to sampling by FGCT)
Total gc time from application startup to sampling (s)

Conclusion
Therefore, if the memory occupied by jmap output is much smaller than RSZ under normal circumstances, you don't have to worry too much unless there are some serious errors, such as OutOfMemoryError caused by full PermGen space, or the RSZ is too high, causing system public anger to be killed by OOM Killer. You should pay attention to the addition of memory and memory, no money to buy memory and swap space, or eliminate them one by one based on the components listed above.
The relationship between these memory indicators is: VSZ> RSZ> the actual heap size used by the Java program