Need to know the reason behind the flattish behaviour of memory utilization of Linux based App Service Plan

Question

Need to know the reason behind the flattish behaviour of memory utilization of Linux based App Service Plan

Nayan Chhabhaiya 10

Current scenario: As show in the below attached screenshot, the memory utilization of Linux based App Service Plan is flattish even after the function executions are completed on the Azure Function Apps hosted on App Service Plan (dedicated) and not coming down.

Linux based App Service Plan's usage

Same behavior (flattish memory utilization and not frequently coming down) can be seen in the Memory working set of the Azure Function App.

Azure Function App's Memory working set metrics

Expected behavior: Once the Function execution gets completed, the memory utilization should come down instead of remaining flattish (same as CPU utilization).

Queries:

Please help me in understanding the strange behavior of memory utilization of Linux based App Service Plan.
Is there any way to tweak the memory utilization behavior of Linux based App Service Plan?

Khadeer Ali 5,970 Reputation points Microsoft External Staff Moderator

2025-06-05T16:08:48.48+00:00

@Nayan Chhabhaiya

We've observed that the memory utilization on our Linux-based App Service Plan remains flat and doesn’t reduce even after the Azure Function executions complete. This behavior is expected due to the way Linux App Service Plans manage resources.

Function Apps on Linux run inside containers, and the memory allocated during execution is often held by the runtime (like .NET or Node.js) for future use rather than being immediately released back to the OS. This is why we see memory staying flat, unlike CPU, which drops off once execution ends.

To manage this behavior, we can consider the following:

Auto-heal configuration: Set up rules to recycle the app when memory usage crosses a threshold.

Optimize function code: Release unused objects and avoid memory-heavy operations where possible.

Use a different hosting plan: The Consumption or Premium plan handles memory more dynamically and may better suit use cases where resource deallocation is critical.
Nayan Chhabhaiya 10 Reputation points

2025-06-06T09:36:33.0533333+00:00

Thanks @Khadeer Ali for your response on my initial queries.

When garbage collector runs and removes unwanted objects from memory, so the memory which got freed up is held by runtime (like Java, .NET, Node.JS) OR it is released back to the OS? - I want to know this in context of Azure Function Apps (App Services) hosted on dedicated/App Service Plans.

And for Java runtime for Azure Function Apps, do you have recommendations (like choosing between multiple garbage collectors, tweaking JVM, etc) which we can follow to get maximum throughput and minimum latency. If you can share some of the recommendations, then I would appreciate it.
Khadeer Ali 5,970 Reputation points Microsoft External Staff Moderator

2025-06-10T09:25:13.4333333+00:00

@Nayan Chhabhaiya ,

Just checking in to see if my earlier response answered your question. If you need more help or have any other questions, just let me know!
Khadeer Ali 5,970 Reputation points Microsoft External Staff Moderator

2025-06-12T17:55:32.3733333+00:00

@Nayan Chhabhaiya ,

Just following up again to see if you were able to resolve the issue or if there's anything else I can assist you with.

1 answer

Your answer

Khadeer Ali 5,970 Reputation points Microsoft External Staff Moderator

2025-06-05T16:08:48.48+00:00

@Nayan Chhabhaiya

We've observed that the memory utilization on our Linux-based App Service Plan remains flat and doesn’t reduce even after the Azure Function executions complete. This behavior is expected due to the way Linux App Service Plans manage resources.

Function Apps on Linux run inside containers, and the memory allocated during execution is often held by the runtime (like .NET or Node.js) for future use rather than being immediately released back to the OS. This is why we see memory staying flat, unlike CPU, which drops off once execution ends.

To manage this behavior, we can consider the following:

Auto-heal configuration: Set up rules to recycle the app when memory usage crosses a threshold.

Optimize function code: Release unused objects and avoid memory-heavy operations where possible.

Use a different hosting plan: The Consumption or Premium plan handles memory more dynamically and may better suit use cases where resource deallocation is critical.
Nayan Chhabhaiya 10 Reputation points

2025-06-06T09:36:33.0533333+00:00

Thanks @Khadeer Ali for your response on my initial queries.

When garbage collector runs and removes unwanted objects from memory, so the memory which got freed up is held by runtime (like Java, .NET, Node.JS) OR it is released back to the OS? - I want to know this in context of Azure Function Apps (App Services) hosted on dedicated/App Service Plans.

And for Java runtime for Azure Function Apps, do you have recommendations (like choosing between multiple garbage collectors, tweaking JVM, etc) which we can follow to get maximum throughput and minimum latency. If you can share some of the recommendations, then I would appreciate it.
Khadeer Ali 5,970 Reputation points Microsoft External Staff Moderator

2025-06-10T09:25:13.4333333+00:00

@Nayan Chhabhaiya ,

Just checking in to see if my earlier response answered your question. If you need more help or have any other questions, just let me know!
Khadeer Ali 5,970 Reputation points Microsoft External Staff Moderator

2025-06-12T17:55:32.3733333+00:00

@Nayan Chhabhaiya ,

Just following up again to see if you were able to resolve the issue or if there's anything else I can assist you with.

Answer 1

@Nayan Chhabhaiya ,

Thanks for your follow-up!

The flat memory usage you’re observing on the Linux-based App Service Plan is expected. When garbage collection (GC) runs in Java (or other runtimes), it frees up unused memory within the JVM, but that memory is not immediately released back to the OS. Instead, it stays allocated for future use, which is why you see memory usage remaining flat even after function execution.

For Java Function Apps, here are some recommendations:

Choose the right GC and use G1GC (default), or consider ZGC for low-latency needs.
You can Set fixed heap sizes: e.g., -Xms512m -Xmx1024m to keep memory predictable.
Enable GC logging it helps analyse memory behaviour (-Xlog:gc*).
Enable Always On it Improves performance and avoids cold starts.
Use performance flags Like -XX:+TieredCompilation and -XX:+AlwaysPreTouch.

These steps could help you manage memory more efficiently, even if the OS metrics don’t show immediate drops in usage. Hope this helps. Do let us know if you have any further queries.

If this answers your query, do click Accept Answer and Yes for "Was this answer helpful." And if you have any further questions, let us know.

Share via

Need to know the reason behind the flattish behaviour of memory utilization of Linux based App Service Plan

1 answer

Your answer