IIS7 w3wp进程挂在回收站上

一个单一的服务器已经开始有时候试图回收僵尸w3wp.exe进程。 一个新的过程是适当的产生,一切似乎工作,除了旧的过程仍然存在,并占用记忆。 任务pipe理器报告,只剩下一个线程,远离那些通常有40到70个线程的活动线程。

使用ProcDump我已经采取了一个完整的内存转储在WinDbg进一步分析。 该机器是WinDbg声明的Server 2008 R2 x64 8核心机器:

Windows 7 Version 7600 MP (8 procs) Free x64 

加载sos后,托pipe线程的打印输出显示如下:

 0:000> !threads ThreadCount: 19 UnstartedThread: 0 BackgroundThread: 19 PendingThread: 0 DeadThread: 0 Hosted Runtime: no PreEmptive Lock ID OSID ThreadOBJ State GC GC Alloc Context Domain Count APT Exception XXXX 1 9d0 000000000209b4c0 8220 Enabled 0000000000000000:0000000000000000 000000000208e770 0 Ukn XXXX 2 c60 00000000020c3130 b220 Enabled 000000013fbe5ed0:000000013fbe7da8 000000000208e770 0 MTA (Finalizer) XXXX 3 a24 00000000020f0d60 880a220 Enabled 0000000000000000:0000000000000000 000000000208e770 0 MTA (Threadpool Completion Port) XXXX 4 97c 0000000002105180 80a220 Enabled 0000000000000000:0000000000000000 000000000208e770 0 MTA (Threadpool Completion Port) XXXX 5 c28 000000000210bfe0 1220 Enabled 0000000000000000:0000000000000000 000000000208e770 0 Ukn XXXX 6 d40 00000000053f9080 180b220 Enabled 00000001bfe75d20:00000001bfe767c8 000000000208e770 0 MTA (Threadpool Worker) XXXX 7 c18 00000000053f9b30 180b220 Enabled 00000000fff95880:00000000fff97210 000000000208e770 0 MTA (Threadpool Worker) XXXX 8 f7c 00000000053fa5e0 180b220 Enabled 000000011fbea268:000000011fbea920 000000000208e770 0 MTA (Threadpool Worker) XXXX 9 91c 00000000053fb090 180b220 Enabled 00000001dfc39138:00000001dfc39670 000000000208e770 0 MTA (Threadpool Worker) XXXX a fb0 00000000053fbd20 180b220 Enabled 00000000fff922b0:00000000fff93210 000000000208e770 0 MTA (Threadpool Worker) XXXX b fc8 00000000053fc9b0 180b220 Enabled 0000000160053ea0:0000000160054778 000000000208e770 0 MTA (Threadpool Worker) XXXX c 538 00000000053fd460 180b220 Enabled 000000017fd8fc98:000000017fd911f8 000000000208e770 0 MTA (Threadpool Worker) XXXX d 604 00000000053fdf10 180b220 Enabled 000000019fd7aa78:000000019fd7c648 000000000208e770 0 MTA (Threadpool Worker) 0 f 2cc 0000000005514c60 220 Enabled 0000000000000000:0000000000000000 000000000208e770 0 Ukn XXXX 10 9bc 00000000020a90c0 220 Enabled 0000000000000000:0000000000000000 000000000208e770 0 Ukn XXXX 11 9c0 00000000056b7a00 220 Enabled 0000000000000000:0000000000000000 000000000208e770 0 Ukn XXXX e 9d4 00000000056b7fd0 220 Enabled 0000000000000000:0000000000000000 000000000208e770 0 Ukn XXXX 12 9d8 00000000056b85a0 220 Enabled 0000000000000000:0000000000000000 000000000208e770 0 Ukn XXXX 13 cb8 00000000056b8b70 220 Enabled 0000000000000000:0000000000000000 000000000208e770 0 Ukn 

然而更感兴趣的可能是剩余单个非pipe理线程的堆栈回溯的输出:

 0:000> ~* kb 2000 . 0 Id: 85c.2cc Suspend: -1 Teb: 000007ff`fffd3000 Unfrozen RetAddr : Args to Child : Call Site 000007fe`fdcc1843 : 00000000`00fd6b60 00000000`00fd6b60 ffffffff`ffffffff 00000000`77bc04a0 : ntdll!ZwClose+0xa 00000000`77ab2c41 : 00000000`77bc1670 00000000`00000000 00000000`77bc04a0 7fffffff`ffffffff : KERNELBASE!CloseHandle+0x13 000007fe`f56537c6 : 00000000`00000000 00000000`00000000 00000000`012da080 000007fe`f5442eac : kernel32!CloseHandleImplementation+0x3d 000007fe`f54443d2 : 00000000`00000007 000007fe`f5443d3c 00000000`00000000 00000000`77bc9997 : httpapi!HttpCloseRequestQueue+0xa 000007fe`f54444c3 : 00000000`00000000 00000000`012e6900 00000000`00000000 00000000`77bd5afa : w3dt!UL_APP_POOL::Cleanup+0x62 000007fe`f549384a : 00000000`012da080 00000000`00c93a28 00000000`012e6900 00000000`00000000 : w3dt!WP_CONTEXT::CleanupOutstandingRequests+0x83 000007fe`f549417a : 00000000`00000000 00000000`0000ffff 00000000`00000000 00000000`77bcf9fd : iiscore!W3_SERVER::StopListen+0x4a 000007fe`f562b5bf : 00000000`012d2f30 00000000`00000000 00000000`00000000 00000000`0000ffff : iiscore!IISCORE_PROTOCOL_MANAGER::StopListenerChannel+0x5a 000007fe`f5626e8f : 00000000`012d2f30 00000000`00000000 00000000`00424380 00000000`00000000 : w3wphost!LISTENER_CHANNEL_STOP_WORKITEM::ExecuteWorkItem+0x7b 00000000`77bcf8eb : 00000000`021782b0 00000000`021782b0 00000000`00000000 00000000`00000001 : w3wphost!W3WP_HOST::ExecuteWorkItem+0xf 00000000`77bc9d9f : 00000000`00000000 00000000`012d2f30 00000000`00424380 00000000`010aa528 : ntdll!RtlpTpWorkCallback+0x16b 00000000`77aaf56d : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!TppWorkerThread+0x5ff 00000000`77be3281 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d 

从堆栈跟踪中可以看出,w3wp进程正在尝试closures并执行清理任务,但由于某种原因,ntdll!ZwClose挂起。 它已经挂了好几天没有改变 – 除了增加的内存使用量外,没有明显的副作用。

w3wp进程不会一直挂断,我还没有find一个可重复的模式。 同时,有什么build议可以进一步debugging?

令人赞叹的研究。

检查RSCA,看它是否仍然具有该应用程序池的句柄,并可以告诉你是否还有任何正在运行的页面。 它可能会变成模式或领导。 您可以在IIS的最高级别钻取,然后打开“工作进程”,然后双击显示的应用程序池。

问题出现在网站的新版本部署的同时吗?

当工作进程被closures时,对象正在被清理出内存。 如果开发人员编写了代码,当对象被“定型”/“处置”时运行,并且此代码引发exception,则该对象不会从内存中删除。 如果无法从内存中删除所有对象,则可能会阻止closures辅助进程。

那就是为什么它不会每次都发生。 这可能是因为这些代码是系统中不经常使用的一部分,因此导致此问题的对象types并不总是存在。

testing的方法是:

  • 启动系统
  • 使用一小部分
  • 手动回收应用程序池
  • 检查僵尸进程
  • 如果不检查系统的不同部分
  • ….

您也可以与开发人员核对清理对象是否有特殊的代码。

在IIS 7.0中,WWW服务不再pipe理工作进程。 相反,WWW服务是HTTP侦听器HTTP.sys的侦听器适配器。 作为监听适配器,WWW服务主要负责configurationHTTP.sys,在configuration更改时更新HTTP.sys,并在请求进入请求队列时通知WAS。

你在这台服务器上运行什么? 应用程序池,它们是集成模式还是经典模式?