哪些请求会导致 w3wp 进程大幅增长？
在生产环境中，如何发现哪些 Asp.Net http 请求（无论是 aspx、asmx 还是自定义）在 w3wp.exe 进程中造成最大的内存压力？ 我这里指的不是内存泄漏。这是一个良好健康的应用程序，可以很好地处理它的所有对象。 Microsoft 的分代 GC 工作得很好。 然而，某些请求会导致 w3wp 进程显着增加其内存占用量，但仅限于请求期间。
这只是 SAAS 应用程序生产环境的成本效率和可扩展性问题，以便定期向开发部门报告最占用内存的“页面”，将（内存）压力返回到它所属的地方，可以这么说。
似乎没有类似的东西：
HttpContext.Request.PeakPrivateBytes 或 .CurrentPrivateBytes
或
Session.PeakPrivateBytes
On a production environment, how can one discover which Asp.Net http requests, whether aspx or asmx or custom, are causing the most memory pressure within a w3wp.exe process?
I don't mean memory leaks here. It's a good healthy application that disposes all it's objects nicely. Microsoft's generational GC does it's work fine.
Some requests however, cause the w3wp process to grow its memory footprint considerably, but only for the duration of the request.
It is simply a question of the cost-efficiency and scalability of a production environment for a SAAS app, in order to regularly report back to the development department on their most memory hogging "pages", to return that (memory) pressure where it belongs, so to speak.
There doesn't seem to be anything like:
HttpContext.Request.PeakPrivateBytes or .CurrentPrivateBytes
or
Session.PeakPrivateBytes
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可能需要使用性能监视器等工具来监视 W3WP.exe 进程的“进程\工作集”并将其记录到数据库中。然后，您可以将其与 IIS 服务器的 HTTP 日志关联起来。
将 Perfmon 数据和 HTTP 日志都写入 SQL 数据库会有所帮助。然后，您可以使用 T-SQL 按观察到的内存压力时间附近的日期/时间显示请求的页面。使用 DatePart 函数构建日期/时间，根据需要舍入到所需的秒或分钟精度。
希望这有帮助。
谢谢，
-格伦
You might want to use a tool like Performance Monitor to monitor the "Process\Working Set" for the W3WP.exe process and record it to a database. You then could could correlate it to the HTTP logs for the IIS Server.
It helps to have both the Perfmon data and HTTP logs both writing to an SQL database. Then you can use T-SQL to bring up requested pages by Date/Time around the time of the observed memory pressure. Use the DatePart function to build a Date/Time rounded to the desired accuracy of Second or Minute as needed.
Hope this helps.
Thanks,
-Glenn
如果您使用
InProc会话状态，则所有会话数据都存储在 w3wp 的内存中，并且可能是其增长的原因。If you are using
InProcsession state, all your session data is stored in w3wp's memory, and may be the cause of it growing.我不会担心这个。
GC 可能在请求期间发生，并且 CLR 正在分配内存来移动事物。或者它可能是 ASPNET 附带的其他定期服务。
除非您准备好对第 0、1、2 代 GC 事件等进行性能计数器分析，否则我不会担心解决这个“问题”。
无论如何，听起来这并不是一个问题——只是出于好奇而已。
I wouldn't worry about it.
It could be that the GC is happening during the request, and the CLR is allocating memory to move things around. Or it could be some other periodic servicing thing that comes along with ASPNET.
Unless you are prepared to go spelunking with perf counter analysis of generation 0,1,2 GC events , and etc, then I wouldn't worry about solving this "problem".
And it doesn't sound like it's a problem anyway - just a curiosity thing.