Shulou(Shulou.com)06/01 Report--

Today, I will talk to you about the restrictions of Docker on JVM, which may not be well understood by many people. in order to make you understand better, the editor has summarized the following content for you. I hope you can get something according to this article.

First of all, let's start with a clich é limitation: we often report errors when using commands such as jmap against Java applications in Docker:

Can't attach to the process: ptrace (PTRACE_ATTACH,..).

This is mainly because tools such as jstack and jmap are implemented in two ways:

The Attach mechanism, also known as Vitural Machine.attach (), mainly uses the Attach Listener thread that interacts with the target JVM through Socket.

Serviceability Agent (in fact, it is also a kind of Attach, which is realized by calling ptrace in Linux).

Starting from version 1.10 of Docker, ptrace is disabled in the default seccomp configuration file, so some operations performed through SA, such as jmap-heap, will report an error, and the Docker official also provides a solution:

Use-cap-add=SYS_PTRACE to explicitly add the specified function: [docker run-- cap-add=SYS_PTRACE.]

Close seccomp / add ptrace to the allowed list: docker run-- security-opt seccomp:unconfined...

In addition to this limitation, I accidentally found such a Bug:JDK-8140793 when I was looking through JDK's JDK BUG SYSTEM some time ago.

GetAvailableProcessors may incorrectly report the number of cpus in Docker container

BUG roughly describes the phenomenon that when Java is running in a Docker container, the number of CPU fetched may be incorrect.

Docker is known to be based on Cgroups and Namespace, and Cgroups is a Linux kernel feature that limits and isolates the resource usage of processes (CPU, memory, disk Imaco, network, etc.), so I guess JVM does not read the restrictions imposed by Docker using Cgroups at run time.

Continue to check this BUG, found that the status is RESOLVED, so continue to search, in the official Blog found such an article

: "Java SE support for Docker CPU and memory limits" (the article relates to JDK-8140793 that reflects CPU calculation errors in Docker, enhanced JDK-8170888 in Docker memory limit, JDK-8146115 that detects container detection and enhanced resource allocation utilization).

It is mentioned in the article that in previous versions of JDK8u121 (Java SE 8u121 and earlier), the number of CPU and memory read by JVM are not limited by Cgroups, so what's wrong with doing so? As far as I know, when we do not explicitly specify some parameters, we often use the data read by JVM to do some default configuration. For example, if you do not explicitly specify-XX:ParallelGCThreads and-XX:CICompilerCount, then JVM will calculate the number of CPU read to set the value, such as runtime\ vm_version.cpp where the number of Threads of ParallelGC is calculated (based on openJDK1.8 b120 below):

If (FLAG_IS_DEFAULT (ParallelGCThreads)) {assert (ParallelGCThreads = 0, "Default ParallelGCThreads is not 0"); / / For very large machines, there are diminishing returns// for large numbers of worker threads. Instead of// hogging the whole system, use a fraction of the workers for every// processor after the first 8. For example, on a 72 cpu machine// and a chosen fraction of 5 os::active_processor_count 8 / use 8 + (72-8) * (5 cpu machine// and a chosen fraction of 8) = = 48 worker threads.unsigned int ncpus = (unsigned int) os::active_processor_count (); return (ncpus

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.