Um único servidor começou a deixar os processos w3wp.exe de zumbi ao tentar reciclar. Um novo processo é gerado corretamente e tudo parece funcionar, exceto que os processos antigos ainda estão presentes e ocupam a memória. O gerenciador de tarefas informa que existe apenas um único encadeamento, longe dos ativos que têm entre 40 e 70 encadeamentos normalmente.
Usando ProcDump Eu tomei um despejo de memória completo para analisar mais no WinDbg. A máquina é uma máquina de 8 núcleos Server 2008 R2 x64 como declarada pelo WinDbg:
Windows 7 Version 7600 MP (8 procs) Free x64
Após o carregamento de sos, uma impressão dos encadeamentos gerenciados revela o seguinte:
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
De mais interesse, no entanto, é provavelmente a saída de um backtrace de pilha para o único segmento não gerenciado que permanece:
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
No rastreamento de pilha, é óbvio que o processo w3wp está tentando desligar e executar suas tarefas de limpeza, mas, por algum motivo, o ntdll! ZwClose está desconectado. Ele ficou pendurado por vários dias sem alterações - e sem efeitos colaterais aparentes, além de uma maior quantidade de uso de memória.
Os processos w3wp não desligam o tempo todo, eu ainda tenho que encontrar um padrão reproduzível. Enquanto isso, alguma sugestão para mais depuração?
Pesquisa impressionante.
Verifique o RSCA para ver se ainda tem um identificador para esse pool de aplicativos e pode informar se ainda há páginas em execução. Pode aparecer um padrão ou lead. Você pode detalhar isso no nível superior do IIS e abrir "Processos de trabalho" e, em seguida, clicar duas vezes no pool de aplicativos, se ele aparecer lá.
O problema apareceu ao mesmo tempo em que uma nova versão do site foi implantada?
Conforme o processo de trabalho está sendo encerrado, os objetos estão sendo limpos da memória. Se um desenvolvedor tiver escrito código que é executado quando o objeto está sendo "finalizado" / "Descartado" e esse código gera uma exceção, o objeto não será removido da memória. Se você não pode remover todos os objetos da memória, isso pode bloquear o fechamento do processo de trabalho.
Depois, há o problema de por que isso não acontece toda vez. Pode ser que esse código esteja em uma parte do sistema que não é usada com frequência e, portanto, o tipo de objeto que causa esse problema não está sempre presente.
A maneira de testar isso seria:
Você também pode verificar com os desenvolvedores se eles têm algum código especial para limpar objetos.
No IIS 7.0, o serviço WWW não gerencia mais os processos de trabalho. Em vez disso, o serviço da Web é o adaptador de escuta para o ouvinte HTTP, HTTP.sys. Como o adaptador do listener, o Serviço da WWW é o principal responsável pela configuração do HTTP.sys, pela atualização do HTTP.sys quando a configuração é alterada e pela notificação do WAS quando um pedido entra na fila de solicitações.
O que especificamente você está executando neste servidor? Pools de aplicativos, eles são modo integrado ou modo clássico?