ASP.NET High CPU llevando servidores a sus rodillas

8

Ok, nuestra nueva compilación tiene picos de CPU del 100% en cada servidor a intervalos aleatorios. Durante largos períodos, hace que el sitio no responda totalmente; esto será en las horas punta cuando personas de diferentes países inicien sesión en el sitio, etc.

Hemos analizado perfmom, perfiladores de memoria, CLR profiler, sql profilers, Red gate ants profiler, probamos pruebas de carga en UAT, pero ni siquiera podemos reproducir el problema. Esto podría significar que solo miles de usuarios que acceden al sitio en vivo hacen que suceda.

Un patrón que notamos fue que el nuevo código, la construcción rota, en realidad usa notablemente menos hilos.

También estamos usando Spring para COI. ¿Tiene esto una reputación de cama?

Para empeorar las cosas, no podemos implementar para vivir debido al impacto comercial, por lo que no podemos reducir el problema al subconjunto de las nuevas funciones que hemos agregado.

Realmente estamos destruidos. ¿Alguien tiene alguna cicatriz de batalla que pueda salvarnos algunas vidas?

¿Qué informan los sensores de temperatura? Me pregunto si su fuente de alimentación no puede seguir el ritmo. (No tengo idea de cómo verificar esto.)

— sarnold

2

Cuando dice que el servidor se cae, ¿puede agregar más detalles, es BSOD? ¿Quiere decir que se reinicia o que se reinicia el dominio de una aplicación?

No hay forma de que un " pico de CPU 100% " pueda "derribar" el servidor. Tendría que estar vinculado al 100% durante bastante tiempo, junto con problemas con la disipación de calor.

— Andrew Barber

1

¿¿Qué está haciendo?? ¿Qué proceso está usando la CPU en el pico? Esta es la pregunta más importante.

— Aliostad el

Actualicé mi pregunta: ¿es esto mejor? Gracias por el -1 :)

3

Sugiero hacer volcados de memoria y analizarlos en WinDdg con Sos. Solucioné algunos problemas en nuestra producción que probablemente no podría diagnosticar sin WinDbg.

Tess Fernández tiene un excelente blog donde puedes aprender a analizar volcados de memoria.

ese blog es un excelente recurso y lo hemos estado usando. Nuestro problema es que no podemos recrear el problema nuevamente y obtener los volcados.

1

Para recrear el problema, puede martillar su sistema de prueba con jmeter ( jmeter.apache.org ) y ab ( httpd.apache.org/docs/2.0/programs/ab.html ). Con estos, multinúcleos, una LAN rápida y algunos colegas, debería poder estresar al servidor lo suficiente.

— Roman

1

Esto generalmente es causado por la limpieza de objetos grandes y de larga duración en el GC ( stackoverflow tuvo este problema, vea el enlace ). ¿Estás almacenando muchas colecciones de objetos en caché o sesión?

Asalto por GC

También le recomiendo que cree y configure un nuevo servidor en producción para probar. Si tiene una locura aleatoria y no sabe por qué y no puede reproducirlo, señalaría con el dedo el hardware o la configuración, no el código.

— Rick Schott
fuente

No podemos poner en funcionamiento ningún código nuevo porque agrega funciones de noticias. Cuando el código estaba activo, el uso del GC era el mismo, incluso para la generación 2. Sin embargo, ¿tiene alguna sugerencia?

No es imposible, pero el hardware y la configuración son casi los mismos que la última implementación a la que hemos vuelto y que está funcionando con éxito.

1

¿Es este un servidor virtual con recursos compartidos o un servidor físico? Si es el primero, quizás podría considerar dedicar recursos a este servidor. Buena suerte...

— Nigel Findlater
fuente

0

Intente usar a cache servercomo interfaz de usuario Apache Traffic Server (ATS).

Si bien esto no resolverá el problema, puede ser útil identificarlo porque al mismo tiempo moverá la carga potencialmente dañina del backend (ver si el frontend también tiene problemas) y hará que las cosas estén menos calientes en el backend, por lo que será Es más fácil ver lo que está mal.

— Gil
fuente

0

Intentar adivinar la falla sin los datos no tiene sentido. Sí, alguien en stackoverflow o en su equipo de ingeniería podría tener suerte, pero eso es solo una mala ingeniería, y no puede hacer un plan sobre cuánto tiempo le llevará probar cada suposición, y si incluso encontraría el problema.

Tienes que reprobar el problema. Jmeter es un buen comienzo debido a su amplitud, pero no podemos recomendar la herramienta adecuada sin conocer nuestra arquitectura.
Iniciar sesión especialmente en su capa de aplicación es imprescindible. Puede habilitar los rastreos de IIS para un rendimiento lento, pero los muppets de Microsoft lo hicieron para que no pueda capturar todo el flujo de la tubería cuando es lento. Si es tan difícil de reprobar, realmente le gustaría que algunos registros lo ayuden a reducir dónde está el problema. (como oh, es cuando llamamos a este proceso almacenado).

El 100% de la CPU es un poco sospechoso en el sentido de que es poco probable que sea E / S (siempre que la base de datos sea otro cuadro, una base de datos lenta no debería causar un 100% de CPU en los servidores web). Necesitas mirar más cerca de casa.

— M Afifi
fuente