0

I am trying to use micronaut to create microservices that have a low memory overhead. From using micronaut I've had some issues with the memory starting low, on startup, but ballooning when put under load and not coming back down.

I am testing it with a small application that takes an item from a rest call, does some work, to simulate a memory spike, and store the results in a database. If I run the jar file the application starts with ~170mb memory and after the induced spike sits around ~700mb. The native image has similar results with albeit lower startup memory. Playing around with the xms and xmx numbers does help the jar version recover after the spike, although it causes the native image to crash during the spike.

Is this an issue with micronaut? Is there anything I can do to help it recover the memory?

Below are my tests and results

Using the micronaut.io/launch to create a java 11 application with kotlin, gradle, and the graalvm plugin. Also I'm using the gradle plugins that are included to build the application and native images.

java -jar build/docker/layers/application.jar

Start up

System memory heap size
~174 mb 50mb used 264mb total

During spike

System memory heap size
~1125 mb 250mb used 520mb total

After spike (which includes a gc call)

System memory heap size
~711 mb 24mb used 88mb total

And with the native image, just the system memory

./build/native-image/application

before during after
13mb 800mb 800mb
seharri
  • 1
  • Have you checked/compared if the issue is with your implentation or with the framework itself? – Michal_Szulc Aug 13 '21 at 10:21
  • "Is this an issue with micronaut?" - The answer to that isn't clear from the info available in the question. "Is there anything I can do to help it recover the memory?" - That depends on what is consuming the memory and how objects are being referenced. If you could share info about what the app is doing aside from "does some work, to simulate a memory spike" or better yet provide a sample app, that would help. If it looks like a bug, filing an issue at https://github.com/micronaut-projects/micronaut-core/issues with a sample app would help. We will be happy to investigate. – Jeff Scott Brown Aug 13 '21 at 15:13
  • 1
    @Michal_Szulc This is a good point, with an absolute bare bones application the system and heap sizes stay more closely linked heap size 100mb system memory 250mb. Which probably means it's related to my database library. I will investigate thank you – seharri Aug 13 '21 at 15:49
  • It appears the majority of the issue was the database library I was using, sql2o, but with some of the other libraries I've tried the application will sit above 300mb which seems high. But as long as the application doesn't have a huge memory spike it does seem to stay reasonably low. – seharri Aug 13 '21 at 21:36

1 Answers1

0

Is this an issue with micronaut?

It is hard to say with the information provided but your comment "It appears the majority of the issue was the database library I was using, sql2o" suggests that it probably isn't.

Is there anything I can do to help it recover the memory?

You could use a runtime profiler like YourKit to track down what is consuming the memory and use that information to identify opportunities to optimize the memory that the app is consuming. The particulars of what you might have to change will depend on knowing why the system is consuming the memory to begin with.

Jeff Scott Brown
  • 26,804
  • 2
  • 30
  • 47
  • That's the problem I'm having, according to YourKit the heap size is only 90mb so there isn't anything I can optimize from that. This appears to be the issue https://stackoverflow.com/questions/4893192/process-memory-vs-heap-jvm – seharri Aug 16 '21 at 16:56
  • "This appears to be the issue stackoverflow.com/questions/4893192/process-memory-vs-heap-jvm " - I think that means the answer to your first question is "no". – Jeff Scott Brown Aug 16 '21 at 17:05