Closed sophokles73 closed 2 years ago
Thank you for reporting this, we will take a look into it and get back to you
@oubidar-Abderrahim any news on this?
You can assign this bug to me @oubidar-Abderrahim if you want.
This seems to be related to build time initialization of certain container/cgroup classes. ContainerInfo
seems to be one candidate which would need runtime init instead. It looks to me the quota/period settings (which --cpus
translates to) are being looked up on the hosted platform which seems incorrect.
Yep:
$ sudo podman run --rm -ti --memory 100m --memory-swap 100m --cpus 1.0 -v $(pwd):/opt/test:z fedora:35
[root@a3b0e269d3ff /]# /opt/test/testcontainerlimits
running on Java VM [version: 11.0.13, name: Substrate VM, vendor: Oracle Corporation, max memory: 80MiB, processors: 1]
Sorry I had some issues with docker and reproducing the issue and it took to long, Thanks @jerboaa I'll assign it to you
This is sufficient to reproduce:
$ cat TestContainerLimits.java
public class TestContainerLimits {
public static void main(String[] args) {
System.out.printf("running on Java VM [version: %s, name: %s, vendor: %s, max memory: %dMiB, processors: %d]%s",
System.getProperty("java.version"),
System.getProperty("java.vm.name"),
System.getProperty("java.vm.vendor"),
Runtime.getRuntime().maxMemory() >> 20,
Runtime.getRuntime().availableProcessors(),
System.lineSeparator());
}
}
$ javac TestContainerLimits
$ native-image TestContainerLimits
[...]
$ ./testcontainerlimits
running on Java VM [version: 11.0.13, name: Substrate VM, vendor: Oracle Corporation, max memory: 3836MiB, processors: 4]
$ sudo podman run --rm -ti --memory 100m --memory-swap 100m --cpus 1.0 -v $(pwd):/opt/test:z fedora:35
[root@074e0336c0da test]# /opt/test/testcontainerlimits
running on Java VM [version: 11.0.13, name: Substrate VM, vendor: Oracle Corporation, max memory: 3836MiB, processors: 4]
The last line is supposed to report [...] processors: 1
but it reports the same as outside the container (with no limits).
@jerboaa yes, and it should also report the limited amount of memory (100m) instead of the 4GB outside of the container ...
@jerboaa yes, and it should also report the limited amount of memory (100m) instead of the 4GB outside of the container ...
Yes, thanks. Note that Runtime.getRuntime().maxMemory()
is not a good indicator of that, though. The container limit is supposed to represent the total available memory (including native), while maxMemory()
is the maximum heap size. Thus, it'll always be less than that in the reporting.
This is a cgroup v2 specific issue where the container detection code ported from OpenJDK contained a bug. I'll see if I can craft a regression test for this.
Suggested fix with regression test in: https://github.com/oracle/graal/pull/4195
@oubidar-Abderrahim Could you please help find reviewers for the suggested PR, please?
Ah, nvm, Paul assigned Aleksandar.
@sophokles73 Feel free to try your reproducer with the latest 22.0 dev builds from here:
https://github.com/graalvm/graalvm-ce-dev-builds/releases/tag/22.1.0-dev-20220126_0118
Issue should be fixed. Please let me know if not.
@jerboaa I have tested the latest 22.1.0 dev graal vm with my reproducer and this works as expected :-)
Thanks a lot!
@jerboaa I have tested the latest 22.1.0 dev graal vm with my reproducer and this works as expected :-)
Thanks a lot!
Anytime. Thanks for verifying. Appreciate it!
I have built a native executable from a simple Java class using the
native-image
toolThe class prints cgroup related information to the console and then outputs the VM's max heap and number of available processors as reported by
Runtime.getRuntime().maxMemory()
andRuntime.getRuntime().availableProcessors()
. I have then put the native executable into a Docker image and run it with memory and CPU limits set to 100m and 1.0 (CPUs) respectively. However, the native executable outputs the memory (25GB) and CPUs (8) available on my host computer instead of the expected < 100m memory and 1 CPU.Steps to reproduce
run the pre-built Docker image
or
build from source
git clone https://github.com/sophokles73/graal-test
My Environment
Output from the native executable run in a container
This is the output when running the pre-built container on my machine
Output from the class when run in a container using OpenJDK 17
Output of native-image when creating the native executable
Docker environment