Docker View JVM Memory Usage

1. Enter the host machine of the docker container and view the container id running the specified image (the first column of the result):

docker ps | grep myImageName (or docker ps | grep java)

2. Enter the container:

docker exec -it containerId sh

3. Enter the top command directly:

top

You can see the basic container usage information: pid, vsz, cpu, command, etc. (ctrl+c or q, exit top)

4. View more specific jvm memory usage:

top -m

Among them, vsz: Virtual Memory Size, virtual memory size, indicates all memory that the process can access, including swapped memory and shared library memory.

rss: Resident Set Size, resident memory set size, indicates how much memory the process occupies in RAM, and does not include the virtual memory occupied in SWAP. Even the memory size of shared libraries in memory is included, including the complete memory in the stack and heap.

SHR: shared memory, shared memory.

Replenish:

ps -ef | grep java or docker top container id to view some information about pid.

ps aux | grep java.

top -p pid.

RSS is the Resident Set Size, which indicates the memory size allocated to the process.

RSS does not include memory that goes into swap partitions.

RSS includes the memory occupied by shared libraries (as long as the shared libraries are in memory)

RSS includes all allocated stack memory and heap memory.

VSZ represents the virtual memory allocated by the process.

VSZ includes all memory accessible to the process, including what goes into swap, and memory occupied by shared libraries.

VSZRW: I didn’t find the specific meaning on Baidu, but I guess it is the size of the virtual memory initially requested.

docker stats container name or docker stats container id, the results are as follows:

CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
 

Supplement: JVM parameter tuning under docker containerization

1. JVM heap memory settings

The Java service running in the Docker container has experienced several memory overflow exceptions. In fact, this has a lot to do with the Docker containerization of the Java program. Java and Docker are not natural friends. Docker can set memory and CPU limits, which are implemented through Linux cgroup technology at the bottom layer, but Java JVM cannot automatically detect them.

We can solve this problem by using Java's Xmx flag to manually specify the size of the heap memory or by using the JVM flag provided by a higher version of JDK.

question:

For older versions of Java 8 (versions before update 131), the available memory and CPU number of the JVM are not the available memory and CPU number that Docker allows you to use.

For example, the Docker container is limited to 1 GB, but the old version of Java cannot recognize this limit. When the business grows, the JVM will apply for more memory, which may far exceed this limit. But if too much memory is used, docker will take action and kill the Java process inside the container, which is obviously not what we want!

Currently, our production environment uses Java 8. This problem can be solved by limiting the heap memory size through -Xmx. However, there are actually two limits here, one is the memory limit of the docker container, and the other is the limit of the jvm heap memory.

Solution:

This premise requires the Dockerfile support of the Java program:

# Initial image FROM adoptopenjdk/openjdk8
# The jar package name needs to be changed to project name-version number, with app.jar remaining unchanged ADD example-sun-1.0.jar app.jar
# Configure JVM startup parameters ENV JVM_ARGS=${JVM_ARGS}
EXPOSE 8080
# Optimize jvm parameter configuration to start ENTRYPOINT java ${JVM_ARGS} -Djava.security.egd=file:/dev/./urandom -jar app.jar

Specifically, add the following parameters to the environment variable env in the k8s deployment.yaml deployment file, and it will be loaded when the JVM starts

- name: JVM_ARGS
 value: -Xmx1024m -Xms512m

Xmx1024m #Set the maximum value of jvm heap memory

-Xms512m #Set the minimum value of jvm heap memory

Here, the minimum heap memory is set to 512m and the maximum memory is set to 1024m. When adjusting the heap memory, do not simply increase it. Carefully analyze the reasons for the excessive memory usage and whether there are any code problems.

JVMs with higher versions of Java 9 (8u131+) provide a better solution

Use JVM flags: -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap

Force JVM to check Linux's cgroup configuration. In fact, Docker uses Linux's cgroup technology to limit container resources such as memory. Now if the application reaches the limit set by Docker (for example 1G), the JVM can see this limit and will try GC operations.

If the memory limit is still exceeded after gc, the JVM will do what it should do, such as throwing an OutOfMemoryException. In other words, the JVM can recognize these settings of Docker.

2. GC log printing and OOM automatic dump

During the program running, you can also print GC logs to facilitate troubleshooting. At the same time, when Java OutOfMemory exception occurs, you can dump the heap memory to facilitate troubleshooting. Set the following parameters:

- name: JVM_ARGS
 value: -Xmx1536m -Xms512m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/logs/my-heap-dump.hprof -Xloggc:/logs/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps

Parameter meaning:

# Automatically dump the memory file when memory overflow occurs -XX:+HeapDumpOnOutOfMemoryError
############# Specify the dump file address as the service print log folder/logs (mounted)
-XX:HeapDumpPath=/logs/my-heap-dump.hprof
############# Print service gc log-Xloggc:/logs/gc.log
# Output detailed GC log -XX:+PrintGCDetails
# Format the output timestamp 2020-09-17T19:45:05.680+0800
-XX:+PrintGCDateStamps

The above is my personal experience. I hope it can give you a reference. I also hope that you will support 123WORDPRESS.COM. If there are any mistakes or incomplete considerations, please feel free to correct me.