gpt4 book ai didi

azure - 当应用服务计划有 7 GiB 时,WebJob 只能访问 2 GiB 内存

转载 作者:行者123 更新时间:2023-12-02 06:16:58 27 4
gpt4 key购买 nike

我有一个如下所示的 Azure 应用服务计划,该计划应该有 7 GB 内存。

P2V2
420 total ACU
7 GB memory
Dv2-Series compute equivalent
83.22 USD/Month (Estimated)

我使用它来托管具有单个连续 WebJob 的单个应用程序。当然,该应用程序本身有一个网站,但我根本不使用它。

此外,我的服务计划中只有 1 个应用程序实例,因此这并不是因为多个实例共享总共可用的 7 GiB 内存。

服务计划有 2 个部署槽,1 个用于生产,1 个用于暂存。两个应用程序(生产中和暂存)都已关闭,因为 WebJob 可以在应用程序本身关闭时继续运行。

这是我所看到的令人费解的地方。从应用服务计划概述页面来看,它显示我正在使用大约 45% 的可用总内存。 enter image description here

但有时我会遇到 OutOfMemoryException,因此我开始检查我的 WebJob 实际使用了多少内存。

事实证明,它使用了 2 GiB 可用物理内存中的 1.6 GiB,而不是我预期的 7 GiB。

我获取当前内存的方式是通过以下代码

var currentMemory = Process.GetCurrentProcess().PrivateMemorySize64;
var totalMemory = GC.GetGCMemoryInfo().TotalAvailableMemoryBytes;

根据此处的文档 https://learn.microsoft.com/en-us/dotnet/api/system.gcmemoryinfo.totalavailablememorybytes?view=net-6.0#System_GCMemoryInfo_TotalAvailableMemoryBytes

This property value will be the value of the COMPlus_GCHeapHardLimit environment variable, or the Server.GC.HeapHardLimit value in runtimeconfig.json, if either is set.

If the program is run in a container, this value is an implementation-defined fraction of the container's size.

Otherwise, the value of the property is the physical memory on the machine that was available for the garbage collector to use when the last garbage collection occurred.

由于我没有设置环境变量、runtimeconfig.json 并且它不是容器,所以我认为 GC.GetGCMemoryInfo().TotalAvailableMemoryBytes正确返回虚拟机上我的 WebJob 可用的总物理内存,即 2 GiB。

感谢下面 Vova 的评论,我还找到了这篇文章。 https://learn.microsoft.com/en-us/azure/app-service/faq-availability-performance-application-issues#i-see-the-message--worker-process-requested-recycle-due-to--percent-memory--limit---how-do-i-address-this-issue-

确实有道理;同时,在我看来,这篇文章是针对应用服务本身的。 WebJob 作为独立于网站的进程运行。虽然症状是一样的。看来我的 WebJob 是 JIT 到 32 位而不是 64 位。

我的 WebJob 构建配置

.NET 6 Console Application
Platform: Any CPU

无论如何,我的应用服务配置设置为 x64,如下所示。 enter image description here

我试图了解我做错了什么,因为我认为 Azure 在这里做的是正确的事情。

我正在使用 Azure 应用服务来运行 WebJob,因此我的目标是通过可用的最小/最便宜的 SKU 最大限度地提高 WebJob 的可用内存。

最佳答案

我发现问题在于我如何通过在 ADO 管道中创建的 run.cmd 启动脚本运行 WebJob。

dotnet MyWebJob.dll 导致 GC.GetGCMemoryInfo().TotalAvailableMemoryBytes 返回 2 GiB 作为我的 WeJob 的总可用内存,而我的 WebJob 本身 Process.GetCurrentProcess ().PrivateMemorySize64 仅消耗 1.5 GiB 内存。

由于我的 ADO 管道还生成特定于 Windows 平台的可执行文件,因此我还有一个可以运行的 EXE。通过调用 EXE MyWebJob.exe 启动我的 WebJob,GC.GetGCMemoryInfo().TotalAvailableMemoryBytes 返回 5.5 GiB 作为我的 WeJob 的总可用内存,而我的 WebJob 本身 Process.GetCurrentProcess().PrivateMemorySize64 内存膨胀至 3.5 GiB。

出现这两种不同行为的原因是 Path 环境变量同时包含 dotnet SDK x86 和 x64,并且在值中 dotnet x86 位于 dotnet x64 之前。因此,当我执行 dotnet MyWebJob.dll 时,系统正在使用 x86 dotnet 运行时,如调试控制台所示。

C:\home>dotnet --info
.NET SDK (reflecting any global.json):
Version: 6.0.100
Commit: 9e8b04bbff

Runtime Environment:
OS Name: Windows
OS Version: 10.0.14393
OS Platform: Windows
RID: win10-x86
Base Path: C:\Program Files (x86)\dotnet\sdk\6.0.100\

Host (useful for support):
Version: 6.0.0
Commit: 4822e3c3aa

我修改了负责为 WebJob 生成启动脚本的 ADO 任务,以显式使用 x64 版本的 dotnet。 [01/07/2022 00:21:06 > 52cb62:信息] C:\local\Temp\jobs\Continuous\MyWebJob\n04q3opt.krt>“C:\Program Files\dotnet\dotnet.exe”MyWebJob .dll 这解决了问题。

结果与不使用 dotnet 直接运行 EXE 的结果相同,如我上面所示。

关于azure - 当应用服务计划有 7 GiB 时,WebJob 只能访问 2 GiB 内存,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/70600124/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com