Home > Mobile >  Why simple Spring cloud Run is taking so much RAM
Why simple Spring cloud Run is taking so much RAM

Time:03-28

When a simple( just sample) Spring Boot Application in Cloud Run , There is no files being written, but th application gets terminated with following error.

Memory limit of 256M exceeded with 257M used. Consider increasing the memory limit, see https://cloud.google.com/run/docs/configuring/memory-limits

When I look at Deleting temporary files then it says the disk storage is in-memory, so if code is not writing any files, then how these files are being written. How to find these files using

gsutil ls -h gs://projectName

CodePudding user response:

An interesting question.

Are you confident that your app isn't writing any files? I bet it is.

There's a wrinkle to Google's statement. Anything written to /var/log is not part of the in-memory filesystem|quota and is shipped to Cloud Logging.

I think Google should consider providing metrics that help differentiate between the container's process(es)' use of memory and the in-memory filesystem's use. Currently there is no way to disambiguate this usage (Cloud Monitoring metrics for Cloud Run). Perhaps raise a feature request on Google's public issue tracker?

To answer you question, you may want to consider running the container locally. Then you can grab the container's (process') process id (PID) and then try e.g. ls -la /proc/${PID}/fd to list files that the container is producing.

I considered suggesting Google Cloud Profiler but it requires an agent for Java and so it would be cumbersome to deploy to Cloud Run and would not obviously yield an answer to your question.

CodePudding user response:

It's the problem of Java, and it's worse with Spring. Java, with a standard JVM use a lot of memory by default (at least 128MB). When you run Spring on top of java, tons of beans are loaded in memory, the library loaded in memory and it take easily more than 350Mb for a simple hello world app.

I wrote an article on that. You have 2 solutions to mitigate the cold start and the memory (and container) size:

  • Use raw java without heavy framework
  • Use native compilation (graalVM for instance).

I tried to optimize the JVM used (a micro JVM) or Spring directly (limit the beans loaded, use lazy loading, add JVM parameters). It saved a few second at startup (cold start) but not really memory.

I also started to investigate AppCDS with a former Google CLoud Dev Advocate, but he left the company 1 year ago and I stopped my effort (I'm no longer a Java/Spring developer, but I always liked the concept and I worked on it).

Eventually, you can also have a look to new generation framework, like Micronaut, Quarkus or Vert.x

  • Related