问题描述
在使用 Windows-based Azure Web App（32位）时，经常遇到以下疑问：
- 进程内存上限是多少？
- 不同托管模式下可用内存如何计算？
本文将针对这些问题进行详细解答。
问题解答
一、32 位程序最大能使用多少内存？
理论上限约为 4GB
32 位程序的内存地址由 32 个二进制位组成，因此理论上可以有 2³² = 4,294,967,296 种不同的内存地址。每个内存地址指向 1 Byte 的空间，所以：
32 位地址空间 = 2³² Byte (410241024*1024 B) ≈ 4GB
为什么文档中提到 2GB？
Windows 默认将 4GB 虚拟地址空间划分为：
- 2GB 用户态：供应用程序使用
- 2GB 内核态：供操作系统使用
因此，默认情况下单进程可用用户态内存为 2GB。这只是默认行为，并非 32 位程序的绝对上限。在某些情况下（例如启用 Large Address Aware + 特定系统配置），可以超过 2GB。
二、In-Process 与 Out-Of-Process 模型对内存的影响
两种托管模式对比
| 特性 | In-Process | Out-of-Process |
|---|---|---|
| 宿主进程 | w3wp.exe（IIS 工作进程） |
dotnet.exe（独立进程） |
| 进程数量 | 应用与 IIS 共享同一进程 | 应用运行在独立进程中 |
| 内存隔离 | 与 IIS 共享内存空间 | 独立内存空间 |
| 性能 | 更高（无进程间通信开销） | 略低（需通过 HTTP 代理） |
In-Process 模式内存行为
- 应用代码直接运行在
w3wp.exe进程中 - 内存上限受
w3wp.exe进程限制：- 32 位：约 2GB（Windows 用户态默认限制）
- 64 位：受 Sandbox 限制
- 注意：应用内存 + IIS 模块内存 共同占用进程空间
Out-of-Process 模式内存行为
- 应用运行在独立的
dotnet.exe进程中 - Kestrel 作为边缘服务器，IIS 仅作为反向代理
- 内存上限独立计算：
- 32 位：约 4GB（可寻址上限）
- 64 位：受 Sandbox 限制
Azure App Service Sandbox 限制
在 Azure App Service 中，存在一个核心限制：
Sandbox 限制：进程实际能获得的最大物理内存 = 机器物理内存 × 75%
| App Service Plan | 物理内存 | 64位进程可用内存（约） |
|---|---|---|
| B1/S1 | 1.75 GB | ~1.3 GB |
| B2/S2 | 3.5 GB | ~2.6 GB |
| B3/S3 | 7 GB | ~5.25 GB |
| P1v2 | 3.5 GB | ~2.6 GB |
| P2v2 | 7 GB | ~5.25 GB |
| P3v2 | 14 GB | ~10.5 GB |
总结：
- 32 位进程：永远无法突破约 4GB 的可寻址限制（受托管模式影响不大）
- 64 位进程：会触及 Sandbox 限制（最大约为物理内存的 75%）
三、多个虚拟目录时的内存计算方式
当同一 App Service 下存在多个虚拟目录（vdir）时：
In-Process 模式
- 所有虚拟目录共享同一个
w3wp.exe进程 - 内存上限为该进程的总上限（32位约2GB，64位受Sandbox限制）
- 各应用间无内存隔离，一个应用内存泄漏可能影响其他应用
Out-of-Process 模式
- 每个虚拟目录会生成独立的
dotnet.exe进程 - 每个进程单独计算可用内存上限：
- 32 位 → 约 4GB（实际可能更低，取决于系统配置）
- 64 位 → 受 Sandbox 限制（机器内存 × 75%）
- 多个站点共享同一台 VM 的物理内存，进程间会相互竞争资源
- 优势：进程隔离，一个应用崩溃不影响其他应用
四、SCM（Kudu）进程是否计入总内存？
是的。SCM 进程也运行在同一台 VM 上，其内存占用会一并计入 App Service Plan 的物理内存使用量。
Kudu 典型内存占用：约 200MB - 500MB（视操作而定）
五、如何监控 App Service 内存使用？
方法一：Azure Portal 指标
在 Azure Portal 中查看 App Service 的 Metrics：
Memory working set：当前工作集内存Private Bytes：进程私有内存
方法二：Kudu 进程管理器
访问 https://<your-app>.scm.chinacloudsites.cn/ProcessExplorer/ 查看：
- 各进程的内存占用详情
w3wp.exe和dotnet.exe的实时内存状态
方法三：Application Insights
启用 Application Insights 后，可监控：
- 内存使用趋势
- 内存异常告警
- GC 行为分析
总结
| 场景 | 内存上限 |
|---|---|
| 32 位进程（理论） | ~4GB |
| 32 位进程（Windows 默认） | ~2GB |
| 64 位进程 | 物理内存 × 75% |
| In-Process（32位） | ~2GB（与IIS共享） |
| Out-of-Process（32位） | ~4GB（独立进程） |
建议：
- 如果应用对内存需求较高，推荐使用 64 位 配置
- 对于需要进程隔离的场景，选择 Out-of-Process 模式
- 定期监控内存使用，避免触及上限导致应用异常
参考资料
-
Virtual Address Space (Memory Management) : https://learn.microsoft.com/en-us/windows/win32/memory/virtual-address-space
-
.NET GC - Heap hard limit percent : https://learn.microsoft.com/en-us/dotnet/core/runtime-config/garbage-collector#heap-hard-limit-percent
-
ASP.NET Core Module (In-Process vs Out-of-Process) : https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/aspnet-core-module
-
Azure App Service Sandbox : https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox