不同托管模式下可用内存如何计算本文将针对这些问题进行详细解答。问题解答一、32 位程序最大能使用多少内存理论上限约为 4GB32 位程序的内存地址由 32 个二进制位组成因此理论上可以有 2³² 4,294,967,296 种不同的内存地址。每个内存地址指向 1 Byte 的空间所以32 位地址空间 2³² Byte (410241024*1024 B) ≈ 4GB为什么文档中提到 2GBWindows 默认将 4GB 虚拟地址空间划分为2GB 用户态供应用程序使用2GB 内核态供操作系统使用因此默认情况下单进程可用用户态内存为2GB。这只是默认行为并非 32 位程序的绝对上限。在某些情况下例如启用 Large Address Aware 特定系统配置可以超过 2GB。二、In-Process 与 Out-Of-Process 模型对内存的影响两种托管模式对比特性In-ProcessOut-of-Process宿主进程w3wp.exeIIS 工作进程dotnet.exe独立进程进程数量应用与 IIS 共享同一进程应用运行在独立进程中内存隔离与 IIS 共享内存空间独立内存空间性能更高无进程间通信开销略低需通过 HTTP 代理In-Process 模式内存行为应用代码直接运行在w3wp.exe进程中内存上限受w3wp.exe进程限制32 位约2GBWindows 用户态默认限制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/S11.75 GB~1.3 GBB2/S23.5 GB~2.6 GBB3/S37 GB~5.25 GBP1v23.5 GB~2.6 GBP2v27 GB~5.25 GBP3v214 GB~10.5 GB总结32 位进程永远无法突破约 4GB 的可寻址限制受托管模式影响不大64 位进程会触及 Sandbox 限制最大约为物理内存的 75%三、多个虚拟目录时的内存计算方式当同一 App Service 下存在多个虚拟目录vdir时In-Process 模式所有虚拟目录共享同一个w3wp.exe进程内存上限为该进程的总上限32位约2GB64位受Sandbox限制各应用间无内存隔离一个应用内存泄漏可能影响其他应用Out-of-Process 模式每个虚拟目录会生成独立的dotnet.exe进程每个进程单独计算可用内存上限32 位 → 约 4GB实际可能更低取决于系统配置64 位 → 受 Sandbox 限制机器内存 × 75%多个站点共享同一台 VM 的物理内存进程间会相互竞争资源优势进程隔离一个应用崩溃不影响其他应用四、SCMKudu进程是否计入总内存是的。SCM 进程也运行在同一台 VM 上其内存占用会一并计入 App Service Plan 的物理内存使用量。Kudu 典型内存占用约 200MB - 500MB视操作而定五、如何监控 App Service 内存使用方法一Azure Portal 指标在 Azure Portal 中查看 App Service 的MetricsMemory working set当前工作集内存Private Bytes进程私有内存方法二Kudu 进程管理器访问https://your-app.scm.chinacloudsites.cn/ProcessExplorer/查看各进程的内存占用详情w3wp.exe和dotnet.exe的实时内存状态方法三Application Insights启用 Application Insights 后可监控内存使用趋势内存异常告警GC 行为分析总结场景内存上限32 位进程理论~4GB32 位进程Windows 默认~2GB64 位进程物理内存 × 75%In-Process32位~2GB与IIS共享Out-of-Process32位~4GB独立进程建议如果应用对内存需求较高推荐使用64 位配置对于需要进程隔离的场景选择Out-of-Process模式定期监控内存使用避免触及上限导致应用异常