【Azure App Service】在App Service for Windows上验证能占用的内存最大值

本文涉及的产品
应用实时监控服务-可观测链路OpenTelemetry版,每月50GB免费额度
应用实时监控服务-应用监控,每月50GB免费额度
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 根据以上测验,当使用App Service内存没有达到预期的值,且应用异常日志出现OutOfMemory时,就需要检查Platform的设置是否位64bit。

问题描述

在创建App Service服务的时候,根据定价层不同,内存使用的最大值也有不同。但在实际测试中,发现内存最大只能占用2GB左右,

而定价层中内存分配明明是大于2GB(比如B3定价层的内存为7GB), 这是一种什么情况呢?

在App Service中Kudu工具上,查看进程分配的内存大小:

 

问题解答


使用一段简短C#代码来进行验证,代码是一个循环,根据URL中输入的数字,循环创建多个100MB大小的对象.

var builder = WebApplication.CreateBuilder(args);
// Add services to the container.
var app = builder.Build();

app.MapGet("/oom/{objs}", (string objs) =>
{
    int objunmbers = int.Parse(objs);
    try
    {
        byte[][] largeArray = new byte[objunmbers][];
        for (int i = 0; i < objunmbers; i++)
        {
            largeArray[i] = new byte[1024 * 1024 * 100]; // 每个对象占用100MB
        }
        return "成功创建大数组对象: " + objs;
    }
    catch (OutOfMemoryException)
    {
        return "内存不足,无法创建大数组对象";
    }
});

app.Run();


代码本地调试,可以看见应用占用内存直线上涨:

部署到Azure App Service后,同样通过Kudu站点Process信息,发现内存的占用的确只有2GB左右,但请求需要更多内存资源时,页面返回:内存不足,无法创建大数组对象

这是因为App Service for Windows默认使用32位操作系统,最大内存只能分配2GB。

当主动修改位64位后,App Service 内存就可以占用到定价层所允许的最大值!

如B3的定价层在Kudu中查看到w3wp.exe进程分配的内存达到了6GB

 

根据以上测验,当使用App Service内存没有达到预期的值,且应用异常日志出现OutOfMemory时,就需要检查Platform的设置是否位64bit。

 

参考资料

I see the message "Worker Process requested recycle due to 'Percent Memory' limit." How do I address this issue?

https://learn.microsoft.com/en-us/troubleshoot/azure/app-service/web-apps-performance-faqs#i-see-the-message-worker-process-requested-recycle-due-to-percent-memory-limit-how-do-i-address-this-issue

The maximum available amount of memory for a 32-bit process (even on a 64-bit operating system) is 2 GB. By default, the worker process is set to 32-bit in App Service (for compatibility with legacy web applications).

Consider switching to 64-bit processes so you can take advantage of the additional memory available in your Web Worker role. This triggers a web app restart, so schedule accordingly.

Also note that a 64-bit environment requires a Basic or Standard service plan. Free and Shared plans always run in a 32-bit environment.

 



当在复杂的环境中面临问题,格物之道需:浊而静之徐清,安以动之徐生。 云中,恰是如此!

相关文章
|
2月前
|
安全 Windows
【Azure Cloud Service】在Windows系统中抓取网络包 ( 不需要另外安全抓包工具)
通常,在生产环境中,为了保证系统环境的安全和纯粹,是不建议安装其它软件或排查工具(如果可以安装,也是需要走审批流程)。 本文将介绍一种,不用安装Wireshark / tcpdump 等工具,使用Windows系统自带的 netsh trace 命令来获取网络包的步骤
72 32
|
2月前
|
开发框架 监控 .NET
【Azure App Service】部署在App Service上的.NET应用内存消耗不能超过2GB的情况分析
x64 dotnet runtime is not installed on the app service by default. Since we had the app service running in x64, it was proxying the request to a 32 bit dotnet process which was throwing an OutOfMemoryException with requests >100MB. It worked on the IaaS servers because we had the x64 runtime install
|
4月前
|
Windows
Windows7电脑启动时提示文件winload.exe无法验证其数字签名,错误代码0xc0000428的解决方法
Windows7电脑启动时提示文件winload.exe无法验证其数字签名,错误代码0xc0000428的解决方法
|
5月前
|
网络安全 API 数据安全/隐私保护
【Azure App Service】.NET代码实验App Service应用中获取TLS/SSL 证书 (App Service Windows)
【Azure App Service】.NET代码实验App Service应用中获取TLS/SSL 证书 (App Service Windows)
|
2月前
|
缓存 Prometheus 监控
Elasticsearch集群JVM调优设置合适的堆内存大小
Elasticsearch集群JVM调优设置合适的堆内存大小
323 1
|
27天前
|
存储 监控 算法
深入探索Java虚拟机(JVM)的内存管理机制
本文旨在为读者提供对Java虚拟机(JVM)内存管理机制的深入理解。通过详细解析JVM的内存结构、垃圾回收算法以及性能优化策略,本文不仅揭示了Java程序高效运行背后的原理,还为开发者提供了优化应用程序性能的实用技巧。不同于常规摘要仅概述文章大意,本文摘要将简要介绍JVM内存管理的关键点,为读者提供一个清晰的学习路线图。
|
2月前
|
Java
JVM内存参数
-Xmx[]:堆空间最大内存 -Xms[]:堆空间最小内存,一般设置成跟堆空间最大内存一样的 -Xmn[]:新生代的最大内存 -xx[use 垃圾回收器名称]:指定垃圾回收器 -xss:设置单个线程栈大小 一般设堆空间为最大可用物理地址的百分之80
|
2月前
|
Java
JVM运行时数据区(内存结构)
1)虚拟机栈:每次调用方法都会在虚拟机栈中产生一个栈帧,每个栈帧中都有方法的参数、局部变量、方法出口等信息,方法执行完毕后释放栈帧 (2)本地方法栈:为native修饰的本地方法提供的空间,在HotSpot中与虚拟机合二为一 (3)程序计数器:保存指令执行的地址,方便线程切回后能继续执行代码
25 3
|
2月前
|
存储 缓存 监控
Elasticsearch集群JVM调优堆外内存
Elasticsearch集群JVM调优堆外内存
51 1
|
2月前
|
Arthas 监控 Java
JVM进阶调优系列(9)大厂面试官:内存溢出几种?能否现场演示一下?| 面试就那点事
本文介绍了JVM内存溢出(OOM)的四种类型:堆内存、栈内存、元数据区和直接内存溢出。每种类型通过示例代码演示了如何触发OOM,并分析了其原因。文章还提供了如何使用JVM命令工具(如jmap、jhat、GCeasy、Arthas等)分析和定位内存溢出问题的方法。最后,强调了合理设置JVM参数和及时回收内存的重要性。