Score:0

Java large heap in container environment

uy flag

I'm trying to run a Jetty webserver on kubernetes, it needs an extremely huge amount of heap ~ 250 GB in our production environment, ~ 50 GB in our test environment.

I'm using jetty:9.4-jdk11, I'm trying to avoid setting Xms or Xmx flags explicitly because the value is different between different environments, for that I thought depending on -XX:MaxRAMPercentage -XX:InitialRAMPercentage would be much better, but no matter what I try I can't get the MaxHeapSize to get past 32178700288 ~ 30 GB.

The Node which has only the Java app on it with a few tiny sidcars, has 64 GB of memory.

Dockerfile

FROM jetty:9.4-jdk11

ENV APP_WAR root.war
ENV APP_EXPLODED_WAR root/
ENV APP_DESTINATION_PATH $JETTY_BASE/webapps/
ENV APP_DESTINATION_WAR $APP_DESTINATION_PATH$APP_WAR
ENV APP_DESTINATION_EXPLODED_WAR $APP_DESTINATION_PATH$APP_EXPLODED_WAR

ADD . $APP_DESTINATION_EXPLODED_WAR

ENV JAVA_OPTIONS -XX:+PrintFlagsFinal -XX:MaxRAMPercentage=90 -XX:InitialRAMPercentage=90 -XX:-OmitStackTraceInFastThrow -XX:+UseStringDeduplication -Xlog:gc*,stringdedup*=debug:file=/tmp/gc.log:time

The container resources settings

resources:
  limits:
    cpu: "8"
    memory: 60G
  requests:
    cpu: "6"
    memory: 60G

Based on these values I should be getting 90% of 60 GB MaxHeapSize ~ 54 GB, not 30 GB. Any idea what am I is missing ?

in flag
Have you confirmed that the `JAVA_OPTIONS` environment variable is actually being applied (that is, do you see the output of that `PrintFlagsFinal` in the logs)?
uy flag
Yes I see it, and I can confirm that it is being applied.
Score:0
uy flag

A JVM argument called -XX:+UseCompressedOops which is enabled by default on Java 11, is the cause, from the documentation.

-XX:-UseCompressedOops
    
Disables the use of compressed pointers. By default, this option is enabled, and compressed pointers are used when Java heap sizes are less than 32 GB. When this option is enabled, object references are represented as 32-bit offsets instead of 64-bit pointers, which typically increases performance when running the application with Java heap sizes of less than 32 GB. This option works only for 64-bit JVMs.
    
It’s also possible to use compressed pointers when Java heap sizes are greater than 32 GB. See the -XX:ObjectAlignmentInBytes option.

Just changing -XX:+ to -XX:- as shown above will disables it.

Using -XX:ObjectAlignmentInBytes is not recommended either in my case, from the same documentation.

-XX:ObjectAlignmentInBytes=alignment

Sets the memory alignment of Java objects (in bytes). By default, the value is set to 8 bytes. The specified value should be a power of 2, and must be within the range of 8 and 256 (inclusive). This option makes it possible to use compressed pointers with large Java heap sizes.

The heap size limit in bytes is calculated as:

4GB * ObjectAlignmentInBytes

Note:

As the alignment value increases, the unused space between objects also increases. As a result, you may not realize any benefits from using compressed pointers with large Java heap sizes.

But I guess it is worth testing.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.