Ok, nossa nova compilação apresenta picos de CPU de 100% em cada servidor em intervalos aleatórios. Por longos períodos, o site deixa de responder totalmente - isso ocorre em horários de pico, quando pessoas em diferentes países fazem login no site, etc.
Examinamos perfmom, criadores de perfil de memória, criador de perfil CLR, criadores de perfil sql, criador de perfil de formigas Red gate, tentamos testes de carga no UAT - mas não conseguimos nem 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 visivelmente menos threads.
Também estamos usando a primavera para o COI - isso tem reputação de cama?
Para piorar as coisas, não podemos implementar 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 estamos destruídos – alguém tem alguma cicatriz de batalha que possa nos salvar algumas vidas?
Responder1
Sugiro fazer dumps 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 Fernandeztem um ótimo blog onde você pode aprender como analisar despejos de memória.
Responder2
Isso normalmente é causado por uma grande limpeza de objetos de longa duração no GC(stackoverflow teve esse problema, veja o link). Você está armazenando muitas coleções de objetos em cache ou sessão?
Também recomendo que você construa e configure um novo servidor em produção para testar. Se você tem uma loucura aleatória e não sabe por que e não consegue reproduzi-la, eu apontaria o dedo para o hardware ou configuração, não para o código.
Responder3
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...
Responder4
Tentar adivinhar a falha sem os dados é inútil. 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 cada palpite e se você encontraria o problema.
- Você tem quereproduçãoo problema. Jmeter é um bom começo devido à sua amplitude, mas não podemos recomendar a ferramenta certa sem conhecer nossa arquitetura.
- Exploração madeireiraespecialmente na sua camada de aplicação é obrigatória. Você pode habilitar rastreamentos do IIS para desempenho lento, mas os muppets da Microsoft fizeram isso para que você não pudesse capturar todo o fluxo do pipeline quando ele estava lento. Se for tão difícil reproduzir, você realmente gostaria de alguns registros para ajudá-lo a restringirondeO problema é. (tipo, ah, é sempre que chamamos esse processo armazenado).
A CPU 100% é um pouco suspeita no sentido de que é improvável que haja 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 web). Você precisa olhar mais perto de casa.