[FOLIO-1032] Error setting max JVM heap size based on cgroup limits in Java-based FOLIO docker containers Created: 16/Jan/18  Updated: 06/Sep/19  Resolved: 06/Sep/19

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Bug Priority: P3
Reporter: John Malconian Assignee: John Malconian
Resolution: Duplicate Votes: 0
Labels: ci
Remaining Estimate: Not Specified
Time Spent: 1 hour
Original estimate: Not Specified

Issue links:
Duplicate
duplicates FOLIO-1729 Use container memory limits to manage... Closed
Sprint:
Development Team: Core: Platform

 Description   

Java-based docker images using the fabric8-based base images log the following error in their logs:

cat: /sys/fs/cgroup/memory/memory.memsw.limit_in_bytes: No such file or directory
/usr/verticles/container-limits: line 46: [: 9223372036854771712: unary operator expected

Because of this error, containers are unable to properly determine the proper amount of RAM to allocate to the JVM when the container is configured with memory limits at runtime.



 Comments   
Comment by John Malconian [ 16/Jan/18 ]

It appears that /sys/fs/cgroup/memory/memory.memsw.limit_in_bytes does not exist on Debian-based host systems. Will need to investigate other options. Possibly an experimental java option called -XX:+UseCGroupMemoryLimitsforHeap.

Comment by John Malconian [ 16/Jan/18 ]

ubuntu@ip-10-36-1-185:/proc/sys/kernel$ sudo docker info
Containers: 20
Running: 20
Paused: 0
Stopped: 0
Images: 20
Server Version: 17.05.0-ce
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 125
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 9048e5e50717ea4497b757314bad98ea3763c145
runc version: 9c2d8d184e5da67c95d601382adf14862e4f2228
init version: 949e6fa
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 4.4.0-1047-aws
Operating System: Ubuntu 16.04.3 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 15.67GiB
Name: ip-10-36-1-185
ID: TVAK:DYFP:YM2U:I43A:EBNV:TTTP:CPGX:E56N:VYNB:WLIU:Q7RH:RG5C
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false

WARNING: No swap limit support

Comment by John Malconian [ 16/Jan/18 ]

Docker spells out the issue with swap limit support and how to enable it in Debian-based distributions pretty clearly here.
https://docs.docker.com/engine/installation/linux/linux-postinstall/#your-kernel-does-not-support-cgroup-swap-limit-capabilities

Our tests systems contain 0 swap. I wonder if enabling swap on these systems is detrimental anyway. If we don't need to swap, we could just use ' /sys/fs/cgroup/memory/memory.limit_in_bytes instead.

Generated at Thu Feb 08 23:10:19 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.