Alta CPU do ASP.NET levando servidores a seus joelhos

Ok, nossa nova compilação está tendo picos de 100% da CPU em cada servidor em intervalos aleatórios. Por longos períodos, o site fica totalmente sem resposta - em horários de pico, quando pessoas de diferentes países acessam o site, etc.

Examinamos perfmom, criadores de perfil de memória, CLR, sql, Red Gate Ants Profiler, tentamos testes de carga no UAT - mas não conseguimos reproduzir o problema. Isso pode significar que apenas milhares de usuários que acessam o site ativo fazem com que isso aconteça.

Um padrão que notamos foi que o novo código - a compilação quebrada - na verdade usa muito menos threads.

Também estamos usando a primavera para o COI - isso tem reputação na cama?

Para piorar as coisas, não podemos implantar para viver devido ao impacto nos negócios - portanto, não podemos restringir o problema ao subconjunto dos novos recursos que adicionamos.

Nós realmente somos destruídos - alguém tem alguma cicatriz de batalha que pode nos salvar algumas vidas?

Sugiro fazer despejos de memória e analisá-los no WinDdg com Sos. Corrigi alguns problemas em nossa produção que provavelmente não conseguiria diagnosticar sem o WinDbg.

Tess Fernandez tem um ótimo blog onde você pode aprender a analisar despejos de memória.

Isso geralmente é causado pela limpeza de objetos de longa duração no GC (o stackoverflow teve esse problema, consulte o link ). Você está armazenando muitas coleções de objetos em cache ou sessão?

Assalto por GC

Também recomendo que você crie e configure um novo servidor em produção para testar. Se você tem loucura aleatória e não sabe o porquê e não pode reproduzi-lo, eu aponto o hardware ou a configuração, não o código.

Este é um servidor virtual com recursos compartilhados ou um servidor físico? Se for o primeiro, talvez você possa dedicar recursos a este servidor. Boa sorte...

Tente usar um cache servercomo front-end Apache Traffic Server (ATS).

Embora isso não resolva o problema, pode ser útil identificá-lo, pois ao mesmo tempo você moverá a carga potencialmente prejudicial do back-end (ver se o front-end também tem problemas) e tornará as coisas menos aquecidas no back-end, para que mais fácil ver o que está errado.

Tentar adivinhar a falha sem os dados não faz sentido. Sim, alguém no stackoverflow ou na sua equipe de engenharia pode ter sorte, mas isso é apenas uma engenharia ruim, e você não pode planejar quanto tempo levará para tentar todas as tentativas e se o seu encontraria o problema.

1. Você tem que reprogramar o problema. O Jmeter é um bom começo devido à sua amplitude, mas não podemos recomendar a ferramenta certa sem conhecer nossa arquitetura.
2. É necessário fazer logon especialmente na camada do aplicativo. Você pode ativar os rastreamentos do IIS para obter desempenho lento, mas os muppets da Microsoft o fizeram para não capturar todo o fluxo do pipeline quando estiver lento. Se for tão difícil reproduzir novamente, você realmente gostaria de alguns logs para ajudá-lo a diminuir onde está o problema. (como oh, é sempre que chamamos esse proc armazenado).

A CPU 100% é um pouco suspeita no sentido de que é improvável que seja E / S (desde que o banco de dados seja outra caixa, um banco de dados lento não deve causar 100% da CPU nos servidores da Web). Você precisa olhar mais perto de casa.