Mastering java in containers - MadridJUG

@jorgemoralespou / @gordillo_ramon
Mastering Java in
Containers

Agenda
What are containers and why they matter
⛾ Brief history of Java and Containers
⛾ Java and Containers

What are containers and why they
matter

Containers for Ops

Kernel namespaces:
sandboxing processes from one another
Control Groups (cgroups):
control process resource allocations
Security:
capabilities drop (seccomp), Mandatory
access control (SELinux, Apparmor)
Linux Containers

Cgroups and Namespaces
Cgroups:
● cpu (cpu shares)
● cpuacct
● cpuset (limit processes to a CPU)
● memory (swap, dirty pages)
● blkio (throttle reads/writes)
● Devices
● net_prio (packet class and priority)
● freezer
Namespaces:
● pid (processes)
● net (network interfaces, routing)
● ipc (system V ipc)
● mnt (mount points, filesystems)
● uts (hostname)
● user (UIDs)

Containers for Devs

OS Dependencies
Runtime dependencies
Application

History of Java and Containers

2000
2010
2005
2015
2000:
JAILS ADDED
TO FREEBSD
2006:
GENERIC PROCESS
CONTAINERS
2008:
KERNEL AND USER
NAMESPACES
2015:
GOOGLE
KUBERNETES
2008:
LINUX CONTAINER
PROJECT (LXC)
2016:
STANDARDS VIA
OCI AND CNCF
2013:
RED HAT
ENTERPRISE LINUX
2013:
DOTCLOUD
BECOMES DOCKER
2007:
GPC RENAMED
CONTROL GROUPS
2003:
SELINUX ADDED TO
LINUX MAINLINE
2015:
RHT CONTAINER
PLATFORM
2001:
LINUX -VSERVER
PROJECT
2013:
DOTCLOUD PYCON
LIGHTNING TALK
2005:
FULL RELEASE OF
SOLARIS ZONES
History of Containers

JDK 1.0
1996
2010
2000
2018
2016
2014
2012
2008
2006
2004
2002
1998
https://en.wikipedia.org/wiki/Java_version_history
JDK 1.2
J2SE 1.3
J2SE 1.4
J2SE 5
Java SE 6
Java SE 7
Java SE 8
Java SE 11
Java SE 10
Java SE 9
6 Months
March2014
History of Java

Java in Containers

$ cat Dockerfile
---
FROM java:8
WORKDIR /
ADD HelloWorld.jar HelloWorld.jar
EXPOSE 8080
CMD java -jar HelloWorld.jar
# Build it
$ docker build -t helloworld .
# Run it
$ docker run helloworld
Docker for java developers 101

Being alone

Sharing your world

We’re not alone

$ docker run openjdk:8u121 java -XshowSettings:vm -version
VM settings:
Max. Heap Size (Estimated): 4.23G
Ergonomics Machine Class: server
Using VM: OpenJDK 64-Bit Server VM
openjdk version "1.8.0_121"
OpenJDK Runtime Environment (build 1.8.0_121-8u121-b13-1~bpo8+1-b13)
OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)
OpenJDK 8u121

Java is Blind by default

$ docker run -m 512MB openjdk:8u121 java -XshowSettings:vm -version
VM settings:
Max. Heap Size (Estimated): 4.23G
OpenJDK Runtime Environment (build 1.8.0_121-8u121-b13-1~bpo8+1-b13)
OpenJDK 8u121

$ docker run -m 512MB openjdk:8u131 java -XshowSettings:vm
-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -version
VM settings:
Max. Heap Size (Estimated): 114.00M
OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-2-b11)
OpenJDK 8u131

$ docker run -m 512MB openjdk:8u131 java -XshowSettings:vm -Xmx=256m
-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -version
VM settings:
Max. Heap Size (Estimated): 256.00M
OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-2-b11)
OpenJDK 8u131

Limit your expectations

Alternative
When your Java < 8u131
Fabric8 run-java.sh
● Set Ratio for container memory
● Set max memory for the container
● Set number of cores available for the
container

Configuration

Red Hat JDK 8 Container Image (NO limits)
-XX:+UseParallelOldGC
-XX:+UnlockExperimentalVMOptions
-XX:+UseCGroupMemoryLimitForHeap
-XX:MinHeapFreeRatio=10
-XX:MaxHeapFreeRatio=20
-XX:GCTimeRatio=4
-XX:AdaptiveSizePolicyWeight=90
-XX:MaxMetaspaceSize=100m
-XX:+ExitOnOutOfMemoryError

Red Hat JDK 8 Container Image (1 cpu, 512 Mb)
-Xms64m
-Xmx256m
-XX:+UseParallelOldGC
-XX:+UnlockExperimentalVMOptions
-XX:+UseCGroupMemoryLimitForHeap
-XX:MinHeapFreeRatio=10
-XX:MaxHeapFreeRatio=20
-XX:GCTimeRatio=4
-XX:AdaptiveSizePolicyWeight=90
-XX:MaxMetaspaceSize=100m
-XX:ParallelGCThreads=1
-Djava.util.concurrent.ForkJoinPool.common.parallelism=1
-XX:CICompilerCount=2
-XX:+ExitOnOutOfMemoryError

/sys/fs/cgroup/memory/memory.limit_in_bytes = 536870912
CGroups: JDK 8 Memory example (512 Mb)
Eden Survivor Tenured Metaspace C Heap
Thread
Stack
-Xmx=256m -XX:MaxMetaspaceSize=100m
Container Max Memory (512 Mb)
Native memory (156 Mb)

Red Hat JDK 8 Mem options for containers (512 Mb)
-Xms64m: Min and initial heap memory (25% of max heap)
-Xmx256m: Max heap memory (50% of max memory of containers)
-XX:MaxMetaspaceSize=100m: Max memory for metaspace
-XX:+UnlockExperimentalVMOptions: enables UseCGroupMemoryLimitForHeap.
-XX:+UseCGroupMemoryLimitForHeap: throw an OutOfMemory if memory exceeds the cgroup max
memory. Deprecated from JDK 10, as it is implemented internally by default.
-XX:+ExitOnOutOfMemoryError: When you enable this option, the JVM exits on the first occurrence of
an out-of-memory error

Huge Pages (Example: Cache)
4 Kb
2 Mb
Usual Memory Management With Huge Pages Pool

CGroups: CPUs example (250 millicores)
/sys/fs/cgroup/cpuacct/cpu.cfs_period_us = 100000 (kernel based)
/sys/fs/cgroup/cpuacct/cpu.cfs_quota_us = 25000 (tuned on CPU quota)
cpu
intensive
100 msec
app app app
app
non cpu
intensive

CGroups: CPUs intensive (250 millicores)
Devil is in the details...
2018-11-02 19:40:33.776 [DEBUG] |com.redhat.meetup.containers.CPULimit| - cycle 406 completed: 10

Red Hat JDK 8 CPU options for containers (1 cpu)
-XX:ParallelGCThreads=1: The number of garbage collector threads can be controlled with this
command-line option.
-Djava.util.concurrent.ForkJoinPool.common.parallelism=1: The fork/join framework provides tools to
help speed up parallel processing by attempting to use all available processor cores – which is
accomplished through a divide and conquer approach. This parameter sets the parallelism of the pool.
-XX:CICompilerCount=2: Sets the number of compiler threads to use for compilation.

Red Hat JDK 8 GC options for containers (1 cpu)
-XX:+UseParallelOldGC: The parallel collector performs minor collections in parallel, Parallel compaction is
a feature that enables the parallel collector to perform major collections in parallel.
-XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=20: By default, the virtual machine grows or shrinks
the heap at each collection to try to keep the proportion of free space to live objects at each collection
within a specific range. This target range is set as a percentage by these parameters.
-XX:GCTimeRatio=4: The throughput goal is measured in terms of the time spent doing garbage collection
versus the time spent outside of garbage collection. sets a goal of 1/5 or 20% of the total time in garbage
collection.
-XX:AdaptiveSizePolicyWeight=90: controls how much previous GC times are taken into account when
checking the timing goal. Bases the timing goal check 10% on previous GC times and 90% on the current
GC time.

CPU pinning (Ex. 16 CPUs)
Without CPU pinning With CPU pinning
tensorflow haproxy spark

numa-node-0 numa-node-1
processsor-1processor-0
Non Uniform Memory Access (NUMA)
CPU0
CPU1
CPU2
CPU3
Memory
Controller
CPU4
CPU5
CPU6
CPU7
Memory
Controller
8 Gb
8 Gb
8 Gb
8 Gb
8 Gb
8 Gb
8 Gb
8 Gb
local access remote access

Hardware-aware location (+NUMA architectures)
Docker parameters
--cpuset-cpus="" (CPU Pinning)
--cpuset-mems="" (Numa arch)
Kubernetes CPU Management Policies
--cpu-manager-policy (CPU Pinning only)
--cpu-manager-reconcile-period

GPUs (Example: NVIDIA)
docker
dockerd
docker-containerd
+ shim
runc
nvidia-container-
runtime-hook
http(s)(+unix)
grpc+unix
libnvidia-container
nvidia-driver
container process

JIT
Cpu
Time
As there is a JIT compilation at startup time,
there’s a high spike in CPU usage for
applications to start up.
NOTE: Containers might need more
CPU to start than to later run, or
startup time will increase.

Where and how do I fit?

Kubernetes resource allocation: Explained
Configuration
● Requests: Minimum amount cpu/memory for the container to run
● Limits: Maximum cpu/memory the container can use/grow-to.
Besteffort
Burstable
Guaranteed
requests
limits
limits
requests
Quality of service
limit
requested
allocated

CPU vs Memory

CPU Overcommitment
GuaranteedBurstableBesteffort
NodeCPUcapacity
req
limit
Guaranteed
NodeCPUcapacity
Bursta
ble
Best
effort
NodeCPUcapacity
req
GuaranteedBurstable
NodeCPUcapacity
req
Best
effort
Guaranteed

GuaranteedBurstableBesteffort
NodeMemorycapacity
req
limit
Guaranteed
OOM
Node
Memory
capacity
Burstable
OOM
NodeMemorycapacity
GuaranteedBurstable
NodeMemorycapacity
req
Besteffort
OOM
Guaranteed
Memory Overcommitment

Layers that makes me cry

build
100 MB layer
50 MB layer
registry
send
Why size matters

build
100 MB layer
50 MB layer
registry
cached
Why size matters
send

build
100 MB layer
40 MB layer
registry
Why size matters
9 MB layer
1 MB layer

build
100 MB layer
40 MB layer
registry
Why size matters
9 MB layer
1 MB layer
cached
send

Layering recommendations
Changes
OS Dependencies
Runtime Dependencies
Application Dependencies
(FINAL)
Application Dependencies
(SNAPSHOT)
Application More frequent
Less frequent

How?
● Jib
https://github.com/GoogleContainerTools/jib
● Fabric8 Maven Plugin - FMP
https://maven.fabric8.io/
● Build your own

JVM Implementations
Amazon Corretto
HotSpot
...and more

In summary...

Time to ask!

Mastering java in containers - MadridJUG

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Mastering java in containers - MadridJUG

Similar to Mastering java in containers - MadridJUG (20)

More from Jorge Morales

More from Jorge Morales (10)

Recently uploaded

Recently uploaded (20)

Mastering java in containers - MadridJUG