-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Memory Consumption Increase after migrating to Amazon Corretto Java 17 #194
Comments
Were looking into this thank you. |
@Rtkverma6 can you please share more details about your use case? I.e. provide the command line options you use for JDK 8 and 17, explain the way how you measure memory consumption and provide the data for JDK 8 and 17. Are you talking about an increase in heap memory usage or in the total native memory footprint (i.e. RSS) of the Java process? |
Hi Simonis, Autumn, In Java 8, we used to start our project with start.jar using megha user and ParNewGC GarbageCollector on jetty server using below command.
After Java 17 Upgrade, as ParNewGC was not supported, we first used G1GC then we shifted to ParallelGC like below
When we used G1GC, there were uneven spikes in heap memory usage like once it is 15% then in 1-1.5 hrs the heap memory usage goes to 60%. The heap memory consumption varies from 10% to 80% and sometimes it goes to OOM also and application crashes. So we assumed G1GC is not stable for our application and we shifted to ParallelGC. After shifting to ParallelGC, the heap memory usage does not show abrupt hikes but have settled to around 50-60% heap usage which used to be 15-20% when using Java8. Also we analyzed our application side by side on Java 8 as well as Java 17 with same load and exactly same configuration like OS, RAM, resource loads etc. and then also we observed same heap memory consumption as above. We are not talking about RSS of java process but heap memory usage. We use following command to log memory usage for megha user Memory usage Pattern on Java 8 Memory Usage Pattern on Java 17 with G1GC Memory usage Pattern on Java 17 with ParallelGC Could you please provide guidance regarding questions asked in initial note. |
I would highly suspect the GC behavior with only Our usual recommendation is to set
To be extra clear, we are talking about Java heap memory usage? Because the memory usage data you provided does talk about VSZ and RSS of Java process :) BTW, that memory usage data also is confusing to me, here is taking the first lines of relevant blocks, and reformatting them for easy comparison:
From this, I can see that VSZ for Parallel GC is almost twice as low in JDK 17, and RSS is only 10% larger in JDK 17. Yet, MEM% says 13.6% in JDK 8 case, and 50.6% in JDK 17 case! How does that make sense? AFAIU, MEM% is the ratio of RSS to the amount of physical memory on the machine. So RSS and MEM% numbers are disagreeing with each other. The only plausible theory I have is that they are running in very different environments. |
Hi Shipilev, Sorry for late response from my side We will use "-Xmx == -Xms, and add -XX:+AlwaysPreTouch." and will update if there are any improvement with these flags on memory consumption. ### To be extra clear, we are talking about Java heap memory usage? Let me share the mem consumption stats for better understanding from a different environment. [root@localhost sys]# grep -iR "31413" * If you have any other suggestions related to flags that can be added or steps that can be taken to reduce %MEM, please provide. Thanks for your assistance. |
Dear Amazon Corretto Support Team,
I hope this message finds you well. We recently migrated our product from Java 8 to Amazon Corretto Java 17, and after the migration, we noticed a significant increase in memory consumption—roughly 2 to 3 times compared to what we observed while using Java 8.
We would like to understand whether this is an expected outcome when upgrading from Java 8 to Corretto Java 17, or if it might be indicative of a specific issue in our configuration or environment. Additionally, we are seeking guidance on possible workarounds or optimizations to reduce the memory footprint after the migration.
Some specific questions we have:
We would appreciate your insights and recommendations to help us optimize our product's performance after this migration.
Thank you for your assistance.
The text was updated successfully, but these errors were encountered: