Ok, nuestra nueva versión tiene picos de CPU del 100 % en cada servidor a intervalos aleatorios. Durante períodos prolongados, el sitio deja de responder por completo; esto ocurrirá en las horas pico cuando personas de diferentes países inician sesión en el sitio, etc.
Analizamos perfmom, perfiladores de memoria, perfiladores CLR, perfiladores sql, perfiladores de hormigas de puerta roja, intentamos 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 provocan que esto suceda.
Un patrón que notamos fue que el nuevo código (la compilación rota) en realidad utiliza notablemente menos subprocesos.
También usamos resortes para el COI. ¿Tiene esto reputación de cama?
Para empeorar las cosas, no podemos implementarlo en vivo debido al impacto comercial, por lo que no podemos limitar el problema a un subconjunto de las nuevas funciones que hemos agregado.
Realmente estamos destruidos. ¿Alguien tiene alguna cicatriz de batalla que pueda salvarnos algunas vidas?
Respuesta1
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ándeztiene un gran blog donde puedes aprender a analizar volcados de memoria.
Respuesta2
Esto suele deberse a la limpieza de objetos grandes y de larga duración en el GC (stackoverflow tuvo este problema, ver enlace). ¿Está almacenando muchas colecciones de objetos en caché o sesión?
También te recomiendo que construyas y configures un nuevo servidor en producción para probar. Si tiene una locura aleatoria y no sabe por qué y no puede reproducirla, señalaría con el dedo el hardware o la configuración, no el código.
Respuesta3
¿Es este un servidor virtual con recursos compartidos o un servidor físico? Si es lo primero, quizás podrías considerar dedicar recursos a este servidor. Buena suerte...
Respuesta4
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 simplemente mala ingeniería y no puede elaborar un plan sobre cuánto tiempo le llevará probar todas las conjeturas y si siquiera encontraría el problema.
- Tienes quereproducciónel problema. Jmeter es un buen comienzo debido a su amplitud, pero no podemos recomendar la herramienta adecuada sin conocer nuestra arquitectura.
- Inicio sesiónespecialmente en su capa de aplicación es imprescindible. Puede habilitar los seguimientos 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 reproducir, le gustaría tener algunos registros que le ayuden a reducirlo.dóndeel problema es. (como oh, es cada vez que llamamos a este proceso almacenado).
El 100% de CPU es un poco sospechoso en el sentido de que es poco probable que sea E/S (siempre que la base de datos sea otra caja, una base de datos lenta no debería causar 100% de CPU en los servidores web). Necesitas mirar más cerca de casa.