2

Im running a java process inside a docker. I have set the xms(388m) and xmx(388m). Sometime after the application is started, the memory consumption of the container exceeds and reaches most ~host memory size and the container gets killed.

  • When i connect to the java process using jprofiler i see that the heap is less than Xmx
  • However the top command inside the container shows what docker stats shows
  • When i run the same java process on the host machine, it memory usage is within the Xmx boundary.

Details:

  1. Docker version 1.12.1, build 23cf638
  2. Host OS: Ubuntu 14.04
  3. Container Image: Ubuntu 14.04 (tried with Ubuntu 16.04 also)
  4. JRE: 1.8.0_77 (tried 1.8.0_112, 1.8.0_121 also) (all are client JREs; i cant use server JRE as this application requires JavaFX. Im also using monocle to run the app in headless mode)

  5. Cmd:

    java -server -Djava.net.preferIPv4Stack=true -Djavafx.monocle.headless=true -Dglass.platform=Monocle -Dmonocle.platform=Headless -Dprism.order=sw -Djsse.enableSNIExtension=false -XX:+ExitOnOutOfMemoryError -XX:+HeapDumpOnOutOfMemoryError -Xms388m -Xmx388m -XX:MetaspaceSize=32m -XX:MaxMetaspaceSize=64m -jar myApp-1.0.jar

I also tried setting MALLOC_ARENAS_MAX=4 (also tried with 2 and 1) after going through multiple forums.

I also tried setting --memory and --memory-reservation when running docker container. In this case the container is killed when it reaches the memory limit.

Observation: through out the life of the jvm, it uses less than Xmx (388m). However the docker stats continue to increase and reaches ~1.2g (host memory is 2g) and at some point causes OOM in java process. So i assume that the GC-freed-memory is not return the container OS.

Any help is appreciated.

EDIT:

I was wrong.

  1. Even outside the container (when i ran on the host) the jvm was consuming same amount of memory. So this is not a problem with docker
  2. Top command results inside and outside the container are same. However the heap memory shown in the profiler was within the bounds
  3. The application uses JavaFX webview which creates lots of short lived threads. I believe this causes stack to grow (not sure of any way to measure this).
Pragalathan M
  • 1,673
  • 1
  • 14
  • 19
  • This is possibly related to [this question](http://stackoverflow.com/questions/40228866/optimizing-memory-leakage-in-javafx/40239829#40239829). – Itai Feb 02 '17 at 17:28

1 Answers1

0

I would suggest limiting the resources to the docker-container itself. If you are using docker-compose to run your container then it can be easily done so by using the - resources tag . That way there is limit to the amount of resources that the docker container would take from the system.

Athul Krishna
  • 31
  • 1
  • The question states they tried limiting it with docker but it just killed the process... – Itai Feb 02 '17 at 17:44