Hello Everyone, My name is Puneet Gupta and I work as a Senior
Software Engineer in the Azure App Service team. Our team enables customers
to self diagnose their apps hosted on Azure App Service
In this video, we will learn about monitoring memory consumption for apps hosted
in Azure App Service and identify apps consuming maximum memory
In future videos, we will dig deeper in to troubleshooting tools that
allow you to debug a specific app but the first step is identifying
which app is consuming maximum memory. App Service
provides Linux and docker hosting scenarios, but we will be covering apps
hosted on Windows stack. Also, we will be focusing on apps
running in the dedicated SKU and the approach shown in this video can be applied to apps
built using any framework or technology.
We start by going to the Diagnose and Solve problems blade for your app. Here we have
different categories and checks that you can run to ensure your apps run healthy
and are following the best practices and recommendations. For troubleshooting
memory issues, we go to Availability and Performance category
Under this section, we run a quick health check of your app and we highlight
key aspects of the app that you should care about. The time duration
defaults to last 24 hours but if you can modify it if needed
We can see the app's failed request rate, app performance
maximum CPU percentage across all instances and the maximum
private bytes of memory consumption by the app. Here we notice
that Max Private bytes memory usage for this app is just 103 MB
but the memory tile is shown as Red. Lets understand why.
Clicking on this tile, opens up the Memory Analysis tool.
Memory Analysis helps in measuring memory consumption of all apps
on the app service plan. The very first thing it checks is the App Service
Plan Density. This check ensures that you have not over-stuffed
the app service plan by putting too many sites and it calls out if you
are within the safe limits. Here we are fine because
we are only running 4 active apps in the app service plan which within the safe limits for this
SKU. Next, we see that the tool identifies
that one app has consumed most of the memory on this app service plan
The app name, as we see is "demohighmemory"
Notice that the app consuming most of the memory is different from the
app that we are currently looking at.
The tool also suggests next steps to further debug the app.
When we scroll below, we see private bytes consumption
in MB for the current app and we can see that the current app's private memory consumption
is only 100 megs so this app is surely not the culprit.
Then we see memory consumption of all
instances belonging to the app service plan and here we can see
that at multiple times in the day, the used memory on the instances
reaches as high as 95% and both the instances
experienced high memory situation. Further, we
have a drilldown view that shows you app level memory consumption for apps
running on the same app service plan. By default,
the instance with the maximum memory usage is selected
The tool calls out apps that are consuming the
most memory.
The graphs show individual memory consumption of each app running on the
instance and this view helps in identifying memory usage at
a given point in time by all apps.
In the memory usage per app section, we
see a breakdown of memory per app and here also the app
consuming the maximum memory is pre-selected
The graphs allows us to see the physical memory consumption in percentage
for each app and the commit size for each app.
We can see individual process Id and process name
belonging to the app that are responsible for memory consumption.
Similarly, we can see the commit size
of each process belonging to this app.
In this manner, we can determine the app or apps are spiking the maximum
memory on every instance. Let's see
if we can figure out why the process Id's were restarting or changing
for the "demohighmemory" app. We can do by going to the
Diagnose and Solve blade for the demohighmemory app and from there we go to
Web App Restarted. The Web App Restart tool is showing our app
processes were recycled because it was consuming more than
90% of the available memory. Azure App Service
has a Proactive Auto-healing feature that recycles your app when it consumes more than
90% of the memory of the instance. This is done to ensure
that your app availability is not impacted and to prevent one bad app
from impacting other apps on the app service plan for an extended number of hours
While this has temporarily mitigated the issue,
the developer of the app should debug the app to understand why it was taking high memory
and prevent this from happening in future.
We also see that some processes were delayed a startup just because the platform
detected that the instances were in a high memory situation
If we scroll down we can see a timeline view of these events.
We covered different memory
terms in this video and I want to quickly list them. Private
bytes is the memory allocated by the app but may not currently be in use.
This memory is private to your process and is not shared by other processes.
This memory may be on the RAM or the page file.
This does not included "shared" memory like the memory used by
the OS DLLs or memory mapped files.
Working is the actual memory in RAM used by the current process.
This represents memory that the code in the app is actively
and currently touching. Commit Size is size reserved
in the page file for the process. When the app needs this memory, the
page is swapped in to the RAM from the page file and when not in use,
it is swapped back to the page file. Here is a simple workflow to be followed based
on what is identified by running the high memory analysis tool.
If a single app is consuming most of the memory, then we should debug the app
to identify why the memory is high. To temporarily mitigate the issue,
you can also restart the app, as that might recover the memory situation for some time.
If we are on a lower tier, we can upgrade the
app to next tier to give it more resources. If multiple
apps are consuming high memory, then it is better to scale up the app service plan to the next tier
so that the apps get more compute resources. It might be related to
the load of requests you are getting. You can also move some apps to a dedicated app service
plan to ensure they don't end up impacting other important apps
In our example, we saw "demohighmemory" is consuming maximum memory
hence it makes sense for us to debug this app further to identify why it is
consuming high memory. This will be covered in the next video.
With that, we come to an end. We hope you find this useful and if
you have any feedback or suggestions, please let us know and stay tuned for any upcoming
videos on this topic. Thank you for watching!