文件处理由HttpHandler引起的"泄漏"?

Øyv*_*ind 5 iis memory-leaks httphandler

我正在遇到一个关于HttpHandler的一个非常好奇的问题,我希望这里的某些人能够阐明这一点.非常感谢您提前阅读本文.

我们创建了一个HttpHandler,它位于IIS网站的管道中,用于提供图像,视频和其他资产.HttpHandler非常轻巧.其唯一目的是检查磁盘上是否存在所请求的媒体资产,如果不存在,则将资产的URL重新写入资产所在的位置.已经以这种方式创建了处理程序,以允许我们将媒体资产迁移到新的文件夹结构中.我们还计划在图像和视频URL上使用处理程序(我将从此处称为URLRewriter)用于SEO.

如前所述,URLRewriter类非常轻量级.我们对它进行了内存分析,并确定它在运行时只消耗大约12B的内存.但是,当我们将处理程序放入IIS管道时,我们会看到一些奇怪的行为,最终会导致大量的内存消耗,并且总是会导致w3工作进程回收.我们看到的行为是这样的:

当请求http://www.ourimageserver.com/media/a/b/c/d/image1xxl.jpg(而不是实际的URL)上的图像请求时,我们注意到W3WP.exe创建并挂起,图像路径中每个文件夹的句柄:

•/ media•/ media/a•/ media/a/b•/ media/a/b/c•/ media/a/b/c/d

这是一个很大的问题,因为我们拥有数十万个媒体资产,这些资产存储在一个非常广泛且非常深的文件夹结构中.当URLRewriter部署到我们的生产环境时,IIS/W3WP创建的句柄数量迅速增长,W3WP的内存消耗也相应增加.在不到一个小时的运行时间(在交通相对平静的时期),W3WP持有的手柄数量超过22000,并且该过程已经死亡.我们还注意到,部署URLRewriter的服务器上的内核内存使用量有所增加.

使用Process Explorer和Process Monitor(无论是否附带VS调试器)仔细检查W3WP的行为,都会发现句柄是在调用URLRewriter之前创建的.实际上,句柄是在触发BeginRequest事件之前创建的.从管道中删除URLRewriter时,不会创建这些句柄.现在,一个非常奇怪的事情是,看起来句柄是由W3WP执行的NotifyChangeDirectory操作创建的.为什么W3WP会要求通知这些目录的更改?我们怎样才能阻止它这样做呢?当然这不是默认/正常行为吗?

如果您对可能导致此问题的原因有任何想法,我将非常感谢您的意见.IIS6和IIS7上的行为是相同的.