I have B3 service plan with 7GB RAM and 3 app services into a resource group. One service requires over 4GB but it throws out of memory exception after 2.4GB usage. It looks like available memory is divided between 3 services evenly. How can I manage RAM usage?
One way I can think of would be to put the apps on separate app service plans. One of your apps requires quite a lot, so why not give it its own plan?
Then you would have one Basic 3 service plan for that app, and maybe a Basic 1 plan for the other 2 if that is enough for them?
Yes, you are correct. The RAM listed for each instance size based on the pricing tier that you choose is for the underlying VM. So, this includes the OS and various infrastructure processes, in addition to IIS and your Web Apps. It is also shared with the App Services deployed under the same App Service plan.
This issue could be related to your web application, you may try the following:
View the memory utilization in Azure new portal
(http://portal.azure.com).
Use kudu Diagnostic Dump to see the information of memory
consumption.
Move the Web App to another App Service plan that has only one Web
App.
I would suggest you refer the blog post How to view the memory utilization of your Azure Web Site for more details.
Related
Consider having two Azure App Services sharing the same App Service Plan and thus the same resources.
Is it possible due to high traffic, error or memory leak that one App Service could bring down the other by pulling all resources?
How about an S-tier App Service which has the staging/deployment slots? Could one of those slots bring down the whole App Service?
Consider having two Azure App Services sharing the same App Service Plan and thus the same resources. Is it possible due to high traffic, error or memory leak that one App Service could bring down the other by pulling all resources?
Yes, and since slots use the same resources this also applies to deployments to a slot. If you want to avoid that think about containerization and limit the max memory and cpu usage or use seperate App Service Plans.
Does Azure charge only for the utilization of App service plan resources or for the number of app services we create under that App service plan? Does the number of app services created under a app service plan effects cost?
I am developing a microservices project and I am unsure of whether to deploy each microservice in a dedicated app service or deploying all in one app service as virtual directories. Cost is a concern for our project.
Thanks.
Does Azure charge only for the utilization of App service plan resources or for the number of app services we create under that App service plan?
Ignoring the Free and Shared tiers, you'll pay only for the App Service Plan (cost per selected machine size x number of instances). You'll pay the same whether you have 0 or 50 Apps on the Service plan (although any other I/O, Storage etc consumed by those Apps will be additional).
(Whereas the free tier allows a max of 10 Apps, and the Shared tier allows 100 Apps)
In theory you can then add as many App Services (apps, e.g. Web Apps, Services, Function Apps etc) as you like on each App Service Plan, however in practice you'll be limited by the overall resources of the VM size and plan you've selected (e.g. 10GB Disk space on Basic, and a B1 only has 1.75GB RAM).
From the Microsoft docs, the recommendation is:
Isolate your app into a new App Service plan when:
The app is resource-intensive.
You want to scale the app independently from the other apps in the existing plan.
The app needs resource in a different geographical region.
I would also add the opinion:
If applicable, keep your environments (Dev, UAT, Prod) isolated, either at App Service Plan level, or consider isolation at Resource Group or Subscription level.
Unless your apps are maxing out CPU usage, while installing as many apps per Service Plan as makes logical sense, but monitor performance and the resource usage on the VM instances as you go.
In my situation, I've typically found that RAM to be the bottleneck, so I would typically try to scale up to a VM size with more RAM to host more Apps before separating out the Apps and adding more Service Plans.
If you are on .Net Core or another stack which doesn't need Windows, I would recommend looking into the Linux Service Plans - they are considerably cheaper than Windows instances. One caveat - as at present, there's a weird limitation which doesn't allow mixing of Windows and Linux Service Plans in the same resource group.
Each App is logically fairly well isolated on the Service Plan instances, so you can add, delete, and deploy apps without interfering with the others.
Although Docker containers can be deployed as an App Service, you might find AKS a better fit.
And More Detail
The terminology around the Azure Managed App Service Plans is somewhat confusing, but to clarify:
An App Service Plan (Service Plan) can have 1 or more managed VM instances
e.g. 1 Service Plan scaled to 3 Instances = 3 VMs to pay for.
Ignoring the Free / Shared tier (on the shared tier you pay for each App), and also ignoring the Isolated tier, you'll pay a fixed monthly cost for each Instance
You can add multiple Apps to each App Service Plan - e.g. Web Apps, Function Apps, Misc. Console Apps, and Docker images. These will be deployed to all instances in the plan.
On the Standard tier and above, you can also configure Deployment Slots on your Apps, which provides the ability to smoke-test and provide continued uptime during deployments, especially in your production environment.
App Service Plans (microsoft.web/serverfarms) account for approximately 40% of our overall Monthly Azure costs
This cost can quickly multiply, especially if you are running multiple isolated environments (Dev, UAT, Prod etc) and if you need to scale out to more than one instance per environment for redundancy or scale reasons.
As at time of writing, indicative VM instance costs on US East are approximately
Dev B1 1.75GB RAM are ~$15pm Linux / ~$50pm Windows
Prod P1V2 3.5GB RAM are ~$80 Linux / ~$150pm Windows
So it's only natural to try and minimize costs by deploying multiple apps to a single VM, especially in a fine-grained Microservice enterprise or system.
I would add to this that if you have an app that is memory intensive, I would definitely isolate it to its own App Service Plan. Since usage limits are at the plan level, you don't want to get errors for mission critical apps due to a runaway app or an app experiencing higher traffic. Another good tip is to set up auto scaling with rules you define by your needs, this will prevent downtime if higher traffic than what the plan allocates is experienced.
Though yes, money can definitely be saved by grouping apps together in the same plan.
Yes, you can save cost by hosting multiple apps in one app service plan. You do not need a separate web app plan for each web app.
Generally the price you pay is for the app service plan and not the web app (Exception here is the shared plan) so your costs do not increase as you add more applications to the same plan.
I'm interested in deploying CPU intensive web app to an Azure App Service instance. I can't find any details around CPU usage and/or limits for Azure app service. My concern is that not having insight into the CPU specs/limitations for my app will not allow me to plan on how to accurately plan the physical cloud-based infrastructure (using Azure app service).
My app will be using the OpenCV computer vision library to do heavy image processing, face detection, and face recognition with hundreds/thousands of high quality images. This is naturally a CPU-intensive process. In a traditional setting (or on-premise Virtual Machine setup), I would at least know the specs on the machine (I.E. cpu specs, etc).
In summary, my question is two-fold:
1) Why doesn't azure app service say anything about the CPUs inside of their PaaS (App Service) context? If they do, where can i learn more about CPU limitations for this?
2) In the context of my application, is my CPU-based question irrelevant? I do read online that certain Azure App Service tiers do auto-scaling (meaning load balancing across more servers for better performance). Will this be sufficient for my need where multiple end-users are processing many photos to do face detection and recognition?
Microsoft represent the performance of the a VM in terms of ACU (https://learn.microsoft.com/en-us/azure/virtual-machines/windows/acu). There are limited number of VM's Available in Azure App Service plan.
App Service plan has both scale up and scale out option. Scale out can be done based on the different rules.
But always do remember that the application architecture will dictate how it will use the scale out option.
Note : I would suggest to use VM if it GPU or CPU intensive, as you will get more option.
As i know standard app service are running on A Series VM but based on the scenario that you explained i suggest you to go with Premium App Service Plan that runs on Dv2 VM's. Hope below article will help you out:
I Suggest you to check the app service overview link and it says what kind of VM is running on back end so you can cross check with the VM specs and you can find the CPU details there.
App Service Plan Overview
App Service Limitation
App Service Overview
My app deployed in Azure with basic tier having 10GB space. Now it showing the usage warning error in Server. So I want change the scale from basic to standard. Then which instance size should choose having ( Small-1 core, Medium-2cores and Large- 4 cores) ? Also while saving following notifications are showing
In Standard mode, if a web app is stopped, billing continues, and changing the scaling for an app affects other apps. Are you sure you want to continue?
This will scale the following web apps in the East US 2 region. This can take several minutes to complete. Your web apps will keep running during the process.
please help
To answer your question, here is a table with App Service sizes in which you can see that the Standard size has 50GB and the Premium has 500GB of disk space.
To answer your other questions:
The reality is that you pay for the App Service Plan, each plan can host dozens of Apps. Think of it as a Platform running all the time that hosts your Apps, if you stop one App, the Platform is still running (because you might have other Apps running on it), and thus, you are still charged for it.
Like I said, because what you pay is the App Service Plan, scaling the Plan will automatically scale all the Apps contained in it, that's the reason of the second message.
Think of the App Service Plan as a server in which you run your Apps, the moment you delete all the Apps in the Plan, the Plan stops billing, but as long as you have at least one App (running or stopped) in it, it will keep charging.
The Azure management dashboard gives you the possibility to monitor metrics such as CPU utilization, network in/out, response time, among others.
But how can you measure consumption/availability of memory? I am running a web app that is memory intensive, and it is hard for me to gauge which instance types (or number of instances) I should provision without having an understanding of the memory situation across time.
Yes, my service is a web role on Azure cloud services, I am not talking about VMs (IaaS) here.
Thanks
In your Azure project, in the Roles folder you'll find a folder for each of your Roles. If you use the latest version of the SDK you'll find a file called diagnostics.wadcfg. This is where you'll be able to configure Performance Counters, like \Memory\Available Bytes. This file will also allow you to configure the sample rate (ex: every 30 sec) and the scheduled transfer period (how frequently the logs should be transferred to your Storage Account).
Then you can use a tool like the Azure Diagnostics Manager to view memory consumption over time.
More information: Using performance counters in Windows Azure
A way to do this from the Management Console:
On the Configure tab for your web role, in the monitoring section, change level to Verbose.
On the Monitor tab at the bottom, click Add Metrics
With monitoring set to Verbose, the available metrics should include Memory Available.