Category: Docker

Written by: Marcel Koert B.S.E.E. | Posted on: | Category:

The cores

This case is more difficult to diagnose, or better: it is more difficult to understand whether the JVM is considering CPU limits or not, since when using the " share and sharing cpu " (as Swarm probably does ) we cannot rely on the classic Runtime.getRuntime().availableProcessors()because there is a bug solved only starting from JVM 9 . In reality, this is not a trivial matter because many APIs rely on this value to size the thread pools, such as for the garbage collector or the fork-join.

This actually sent me into confusion: the response of http: // localhost: 8080 / jvm related to the cores will always be 4 (those of the host) starting the stack in Swarm mode , despite all the changes we can make, but actually we notice differences in performance by varying the limits of the cpu . The only case where it seems to have a correct value is when starting a single container with the parameter --cpuset-cpus:

docker run --name ...

Written by: Marcel Koert B.S.E.E. | Posted on: | Category:

The memory

The problem

So let's start with a simple stack on the image cnj / openjdk-jvm-info . src / main / openjdk / stack-memory-default.yml

1.  version: '3.7'
2.
3.  services:
4.  jvm-info:
5.  image: cnj / openjdk-jvm-info
6.  ports:
7.  - "8080: 8080"
8.  environment:
9.  JAVA_OPTS:>
10. -XX: + PrintFlagsFinal
11. -XX: + PrintGCDetails
12. deploy:
13. resources:
14. limits:
15. memory: 1280

Leaving the container like this,

docker stack deploy -c src / docker / openjdk / stack-memory-default.yml openjdk

the JVM prints its configuration (thanks to -XX: + PrintFlagsFinal and -XX: + PrintGCDetails ) and takes its default values, so the memory should be 1/4 of the total (governed by the parameter -XX: MaxRAMFraction = 4 by default on 64-bit JVM Servers with more than 1Gb of RAM ), or 320Mb. Let's take a look at the application logs and see the calculated -Xmx (which corresponds ...

Written by: Marcel Koert B.S.E.E. | Posted on: | Category:

Java 8/11 and Docker can get along and get along well with a little care even when cgroups put their hand in it: let's see together how to tame the old dear JVM 8.

The backend development in recent years has changed radically for those who let themselves be fascinated and involved by Docker and everything that revolves around him. For many, first of all, it has greatly simplified not only the method of access and interaction with the systems around the application that we are developing, such as the database or the queue broker, but above all it has made it possible to make it simpler and finally within reach writing and maintaining integration tests (as we had already seen). This wave has come to invest also the deployment unit : if before you deployed EAR, WAR or JAR executables, now you deploy Docker images ! If much has changed around our code, however, the latter has remained fairly firm, almost behind. In fact, the jump from Java 8 to later versions (which are now running!) ...

© 2019 Marcel Koert for MeloMar IT BV