This article serves as a step-by-step guide to help us identify and diagnose applications with high memory usage in Microsoft Azure. Understanding the primary terminologies involved is crucial for effective troubleshooting and optimization. By following the steps given below, we will be able to analyze memory usage patterns, detect potential memory leaks, and optimize the performance of our Azure applications.
Primary Terminologies
- Private Bytes: These are the memory that the process has allocated but not necessarily using currently. This memory is not shared with other processes. This does not include shared memory (e.g., operating system DLLs and Memory Mapped files). It includes memory on RAM and Page File.
- Working Set refers to the total physical memory (RAM) used by the process. This represents memory pages recently touched by threads in the process.
- Commit Size is the amount of space reserved in the paging file for the process. Used when its pages need to be swapped out to make room in RAM for other processes.
Diagnosis
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 article can be applied to apps built using any frameworks or technology. We start by going to the Diagnose and Solve Problems Blade for your app.To know more about Azure Virtual machines.
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 we 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. Let’s understand why. Clicking on this tile opens up the Memory Analysis tool.
Memory Analysis helps in measuring the 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 is 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 “Configure AutoHealing Custom Action” tool also suggests the 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 the 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 drill-down view that shows you app-level memory consumption for apps running on the same app service plan as shown below.
By default, the instance with the maximum memory usage is selected. The tool calls out apps that are consuming the most memory. The graphs in the above image 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(as shown above), 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. 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 as shown in the sequence.
The Web App Restart tool is showing our app processes were recycled because it was consuming more than 90% of the available memory.
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.
Conclusion
Effectively identifying and diagnosing high memory usage in your Azure applications is crucial for maintaining optimal performance. By leveraging the power of Application Insights, monitoring memory usage patterns, and employing effective troubleshooting techniques, we can identify memory leaks, optimize memory usage, and enhance the overall performance and stability of our Azure applications.
FAQs On Identify and Diagnose Apps With High Memory in Microsoft Azure
1. How Do I Check My Azure App Service Memory?
Go to APP Service pane, under monitor section choose the option metrics and form the new pane you can retrieve the CPU,RAM and metric as Memory percentage.
2. How Do I Diagnose Azure App Service?
Open the azure portal and go to Azure APP and left side you can find the In the left navigation, click on Diagnose and solve problems.