Tengo una aplicación de servicio WCF alojada en IIS. Al iniciar, busca un recurso realmente costoso (en términos de tiempo y CPU) para usarlo como caché local.
Desafortunadamente, IIS parece reciclar el proceso con bastante regularidad. Así que estoy intentando cambiar la configuración en el grupo de aplicaciones para asegurarme de que IIS no recicle la aplicación. Hasta ahora, he cambiado lo siguiente:
- Limite el intervalo bajo CPU de 5 a 0.
- Tiempo de inactividad bajo modelo de proceso de 20 a 0.
- Intervalo de tiempo regular en Reciclaje de 1740 a 0.
¿Será esto suficiente? Y tengo preguntas específicas sobre los elementos que cambié:
- ¿Qué significa específicamente la configuración del intervalo límite en la CPU? ¿Significa que si se excede un determinado uso de CPU, el grupo de aplicaciones se reciclará?
- ¿Qué significa exactamente "reciclado"? ¿La aplicación está completamente derribada y reiniciada?
- ¿Cuál es la diferencia entre "apagado del proceso de trabajo" y "reciclaje del grupo de aplicaciones"? La documentación para el tiempo de espera de inactividad en el modelo de proceso habla sobre el cierre del proceso de trabajo. Mientras que los documentos sobre el intervalo de tiempo regular en Reciclaje hablan sobre el reciclaje del grupo de aplicaciones. No asimilo del todo la diferencia entre los dos. Pensé que w3wp.exe es el proceso de trabajo que ejecuta el grupo de aplicaciones. ¿Alguien puede explicar la diferencia en la aplicación entre los dos?
La razón para tener etiquetas IIS7 e IIS7.5 es porque la aplicación se ejecutará en ambas y espero que las respuestas sean las mismas entre las versiones.
Imagen de referencia:
Respuesta1
Reciclaje
El reciclaje suele ser* donde IIS inicia un nuevo proceso como contenedor para su aplicación y luego deja que el anterior ShutdownTimeLimitdesaparezca por su propia voluntad antes de que se elimine.
*- normalmente: ver DisallowOverlappingRotation/ Configuración "Desactivar reciclaje superpuesto"
Esdestructivo, en el sentido de que se descarta el proceso original y toda su información de estado. El uso de un estado de sesión fuera de proceso (por ejemplo, State Server o una base de datos, o incluso una cookie si su estado es pequeño) puede permitirle solucionar este problema.
Pero es por defectosuperpuesto- lo que significa que la duración de una interrupción se minimiza porque el nuevo proceso comienza y se conecta a la cola de solicitudes, antes de que al anterior se le diga "tienes [ ShutdownTimeLimit] segundos para salir. Por favor cumple".
Ajustes
A su pregunta: todas las configuraciones en esa página controlan el reciclaje de alguna manera. El "cierre" podría describirse como "reciclaje proactivo", donde el proceso mismo decide que es hora de continuar y sale de manera ordenada.
El reciclaje reactivo es donde WAS detecta un problema y dispara el proceso (después de establecer un W3WP de reemplazo adecuado).
Ahora, aquí hay algunas cosas que pueden causar reciclaje de una forma u otra:
- una ISAPI decide que no es saludable
- cualquier módulo falla
- tiempo de inactividad
- limitación de la CPU
- ajustar las propiedades del grupo de aplicaciones
- como tu mamápuedehan gritado en un momento: "Paradcosecha¡Hazlo o nunca mejorará!"
- Error de "ping" * en realidad no hace ping per se, porque utiliza una canalización con nombre - más "detección de vida"
- todas las configuraciones en la captura de pantalla anterior
Qué hacer:
Generalmente:
DesactivarTiempos de inactividad. 20 minutos de inactividad = ¡boom! ¡El antiguo proceso desapareció! Nuevo proceso en la próxima solicitud entrante. Pon eso en cero.
DesactivarIntervalo de tiempo regular- Varias partes han calificado el plazo de 29 horas como "loco", "molesto" e "inteligente". En realidad, sólo dos de ellas son ciertas.
OpcionalmenteEncenderDisallowRotationOnConfigChange(arriba,Deshabilite Reycling para cambios de configuración) si simplemente no puedes dejar de jugar con él, esto te permite cambiar cualquier configuración del grupo de aplicaciones sin que indique instantáneamente a los procesos de trabajo que es necesario eliminarlo. Debe reciclar manualmente el grupo de aplicaciones para que la configuración surta efecto, lo que le permite preestablecer configuraciones y luego usar una ventana de cambio para aplicarlas a través de su proceso de reciclaje.
Como principio general,dejarhaciendo pingactivado. Esa es tu red de seguridad. He visto a personas desactivarlo y luego el sitio se cuelga indefinidamente a veces, lo que genera pánico... así que si la configuración es demasiado agresiva para tu aplicación aparentemente muy, muy lenta en responder, aléjala un poco. y vea lo que obtiene, en lugar de apagarlo. (A menos que tenga configurado el volcado en modo de bloqueo automático para W3WP colgados a través de su propio proceso de monitoreo)
Eso es suficiente para que un proceso de buen comportamiento viva para siempre. Si muere, seguro que será reemplazado. Si se bloquea, el ping debería detectarlo y debería iniciarse uno nuevo en 2 minutos (de forma predeterminada; el cálculo en el peor de los casos debería ser: hastafrecuencia de ping+tiempo de espera de ping+límite de tiempo de inicioantes de que las solicitudes comiencen a funcionar nuevamente).
La limitación de CPU no esnormalmenteinteresante, porque de forma predeterminada está desactivado y también está configurado para no hacer nada de todos modos; si estuviera configurado para finalizar el proceso, claro, sería un desencadenante de reciclaje. Déjalo así. Nota para IIS 8.x, la limitación de CPU también se convierte en una opción.
Un AppPool (IIS) no es un AppDomain (.Net) (pero puede contener uno o algunos)
Pero... luego nos adentramos en el terreno .Net, y la AppDominioreciclaje, que también puede provocar una pérdida de estado. (Ver:https://blogs.msdn.microsoft.com/tess/2006/08/02/asp-net-case-study-lost-session-variables-and-appdomain-recycles/)
Versión corta, lo hace tocando un archivo web.config en su carpeta de contenido (¡Otra vez con la recolección!), o creando una carpeta en esa carpeta, o un archivo ASPX, o... otras cosas... y eso esacerca detan destructivo como el reciclaje de un grupo de aplicaciones,menoslos costos de inicio del código nativo (es puramente un concepto de código administrado (.Net), por lo que aquí solo ocurren cosas de inicialización de código administrado).
El antivirus también puede desencadenar esto, ya que escanea los archivos web.config, provocando una notificación de cambio, provocando...
Respuesta2
Cheque bondadoso,
¿Por qué reciclamos nuestros grupos de aplicaciones?
si navega por la web para encontrar el motivo por el cual los grupos de aplicaciones están configurados para reciclarse automáticamente de forma periódica,Será difícil encontrar una respuesta razonable que no se relacione con problemas de memoria. Es como si la comunidad en general hubiera aceptado el hecho de que nuestras aplicaciones web(o capas de servicio alojadas en IIS) deberán reciclarse para evitar problemas de memoria.
Siempre he sido de la opinión de queSi su código requiere reinicios periódicos para seguir funcionando correctamente, es evidente que algo anda mal. hay un erroren su código en algún lugar y necesita solucionarlo, en lugar de reiniciar el proceso ocasionalmente para que el problema "desaparezca".
Realmente necesito empezar a centrarme más engestión de la memoriaen .NET y en asegurarnos de que nuestras aplicaciones puedan seguir ejecutándose sin problemas.
Respuesta3
Según el escenario OP (inicialización larga al inicio/calentamiento), otra cosa a verificar esLímite de tiempo de inicio(segundos) que tiene un valor predeterminado de 90 segundos. Si la inicialización tarda más que el límite de tiempo de inicio, el proceso de trabajo puede finalizar.
Respuesta4
La respuesta es, tupoderevitar que AppPool se recicle, pero ustedno debe.
La razón es que si hay una pérdida de memoria, eventualmente consumirá toda la memoria del servidor y Windows mostrará una pantalla azul o arrojará excepciones de falta de memoria que desactivarán otros sitios en el mismo servidor IIS.
Por lo tanto, decida cuánta memoria puede usar ese sitio y establezca la configuración anterior para que se recicle cuando se alcance ese límite.
Normalmente, el reciclaje se realiza con elegancia, por lo que los usuarios finales no se dan cuenta. Pero si utiliza Blazor Server, todas las sesiones se ejecutarán en el servidor y se perderá todo el estado. En la práctica, veo que una aplicación Blazor muestra el mensaje "conectando..." durante unos 5 segundos mientras se produce el reciclaje. En otras palabras, no es adecuado para las aplicaciones Server Side Blazor.
La moraleja de la historia es la que se mencionó anteriormente: asegúrese de que su sitio no pierda memoria. Pruebe su memoria al principio del proceso de desarrollo, no espere hasta que entre en funcionamiento, ya que Blazor Server consume mucha memoria y mi experiencia es que he tenido que dedicar bastante tiempo a depurar problemas de memoria. Esto no es culpa de Blazor, simplemente está en la naturaleza de las aplicaciones de Blazor Server requerir un código muy estricto. Anteriormente en .net, nunca me preocupaba por la memoria, ya que el GC se encargaba de todo eso, pero ejecutar dentro de IIS es una historia diferente.