我之前在处理并发请求下的ETW事件关联时也踩过类似的坑，下面给你几个实用的解决方案和工具推荐，帮你精准统计单个请求的内存消耗：

一、优化PerfView的ETW追踪方案（解决事件关联问题） #

你之前遇到的AspNetReq事件和ObjectAllocated事件无法关联的问题，其实可以通过Activity ID追踪来解决：

• 开启追踪时，除了勾选Microsoft-Windows-ASP.NET的AspNetReq/Start、AspNetReq/Stop事件，还要在Microsoft-Windows-DotNETRuntime里开启ActivityTracking选项，同时勾选ObjectAllocated事件。这样CLR的内存分配事件会自动绑定到当前请求的ActivityID，和ASP.NET的请求事件一一对应。
• 分析时，在PerfView中使用MemoryGroupByActivity功能，直接按ActivityID分组统计，就能得到每个请求对应的总内存分配量，还能展开看具体的分配来源。

二、免费工具推荐 #

• Visual Studio 社区版性能探查器：这是最容易上手的免费工具。打开你的ASP.NET MVC项目后，点击「调试」→「性能探查器」，选择「内存使用」，然后启动会话。捕获数据后，在分析面板里选择「按请求分组」，就能清晰看到每个请求的内存分配详情，包括调用栈里的具体分配点。
• dotTrace 免费版：JetBrains的这款工具免费版支持时间线模式，能直观展示每个请求从开始到结束的内存变化曲线，还能定位到哪些方法在请求期间分配了最多内存，足够应对大部分场景。
• PerfView 进阶分析：刚才提到的Activity ID关联方法，配合PerfView的内置分析脚本，能生成非常详细的请求级内存报告，适合深入排查问题。

三、付费工具推荐（适合生产环境或复杂场景） #

• dotTrace 付费版：比免费版多了实时内存监控、请求级性能与内存联动分析等功能，支持在生产环境附加进程进行追踪，不用重启应用。
• ANTS Memory Profiler：Redgate的这款工具专门针对.NET应用做内存优化，能精准追踪单个请求的内存分配，自动识别内存泄漏点，界面简洁直观，上手成本低。
• Azure Application Insights：虽然是APM工具，但可以配置追踪每个请求的内存消耗，还能长期监控应用的内存趋势，免费额度足够小流量应用使用，适合生产环境持续观测。

四、代码层面的辅助方法（快速粗略统计） #

如果暂时没有工具，也可以通过自定义过滤器做粗略统计：

• 编写一个ActionFilterAttribute，在OnActionExecuting时记录当前进程的私有内存大小（Process.GetCurrentProcess().PrivateMemorySize64），在OnActionExecuted时再次记录，两者的差值可以作为该请求的近似内存消耗（注意：并发下进程内存是共享的，这个数值是粗略参考）。
• 使用System.Diagnostics.Activity类手动标记请求边界，让ETW事件自动关联，方便后续工具分析。

内容的提问来源于stack exchange，提问作者Smooyk