que net mucha memoria deploy consuming consume asp asp.net iis deployment worker-process

asp.net - net - que es iis worker process



Despliegue continuo en ASP.NET(IIS elimina el proceso de trabajo antes de que el nuevo proceso de trabajo esté listo) (5)

Supongo que tiene un escáner de virus u otro tipo de proceso de indexación que bloquea el archivo tan pronto como lo copia.

Estoy tratando de implementar una aplicación web .NET en IIS (7.5) sin ninguna molestia para los usuarios. Me he asegurado de que Deshabilitar el reciclaje superpuesto sea falso, pero sigo teniendo el mismo problema cada vez.

Cada vez que cargo nuevos binarios para el sitio, IIS elimina el proceso de trabajo antes de que haya comenzado uno nuevo. Así que cada vez que cargo nuevos binarios, los usuarios reciben este mensaje de error:

Error del servidor en la aplicación ''/''. No se pudo cargar el archivo o ensamblado ''MyApplicationWeb'' o una de sus dependencias. El proceso no puede acceder al archivo porque lo está usando otro proceso. (Excepción de HRESULT: 0x80070020)

No tengo idea de cómo hacer esto sin problemas. Como es ahora, solo cargo el binario; pero mientras se realiza la carga (o copia local) dará el comportamiento citado anteriormente. También intenté usar un jardín web pero con el mismo resultado.

Lo que no estoy buscando:

  • Cómo resolverlo con equilibradores de carga externos (es una solución funcional, pero es una buena solución para algunos servidores y no funcionará en absoluto si solo hay un servidor)
  • Cómo crear un hack-around con una actualización en una página de error personalizada (ya que tiene algunos problemas obvios pero lo más importante es que no funcionará en absoluto con los servicios web / ajax).

Realmente creo que esto debería ser posible dado http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/24e3c22e-79a9-4f07-a407-dbd0e7f35432.mspx?mfr=true

Actualización: en el artículo anterior dicen:

Sin embargo, dado que el valor de tiempo de espera de apagado de un apagado o inicio es configurable, el proceso de trabajo puede finalizarse mientras todavía se atienden las solicitudes si no finaliza el servicio de las solicitudes existentes dentro del límite de tiempo.

No tengo idea de dónde encontrar este valor ni cuál es su valor predeterminado. Si es menos de unos segundos podría explicar mis resultados.

PD. Lo estoy publicando en SO en lugar de en SF / Webmasters, etc. porque creo que este tipo de conocimiento probablemente será mínimo entre las personas que no están activas en el desarrollo, espero que todo esté bien.


podrías usar app_offline.htm

esta solución no es perfecta, pero podría usar una

<meta http-equiv="refresh" content="5" />

en el archivo htm, por lo que el navegador actualiza automáticamente sin javascript.

aclamaciones


Estoy de acuerdo con la respuesta de Smirkin: actualizar una segunda carpeta y cambiar el directorio de inicio de IIS para que apunte a la otra carpeta. Otra ventaja de esto es que tiene una ruta de reversión fácil (simplemente cambie el directorio de inicio de IIS).

He escrito una publicación con un script sobre cómo hacer esto usando Powershell. Espero que ayude: http://davidduffett.net/post/4833657659/blue-green-deployment-to-iis-with-powershell

Debería poder usar este script directamente desde su sistema de integración continua.


Al implementar aplicaciones ASP.Net, creo una nueva carpeta en el servidor y cambio el directorio de inicio del sitio web dentro de IIS. Esto proporciona una implementación de tiempo de inactividad cero y una posición de reversión rápida en caso de problemas imprevistos. En una actualización futura elimino la versión anterior y repito el proceso para que siempre haya una única posición de reversión.

Actualización - límite de tiempo de apagado

Los detalles que configuran el límite de tiempo de apagado para los trabajadores se detallan en http://www.iis.net/ConfigReference/system.applicationHost/applicationPools/add/processModel . El valor predeterminado es 1 minuto 30 segundos. Busque la sección shutdownTimeLimit en la página vinculada.

Actualización - Más información

Pregunta similar con una gran respuesta

La esencia de esto es que, debido a la sobreescritura de los archivos existentes, el mecanismo de copiado realiza un bloqueo exclusivo en los archivos y que no es posible tener una implementación perfecta sin el uso de app_offline.htm o un mecanismo como el sugerido anteriormente. Tome una lectura de la respuesta vinculada, ya que entra mucho más en profundidad.


Mientras que la respuesta de Smirkin proporciona una manera perfecta para que un administrador implemente un sitio con poco o ningún tiempo de inactividad, y debe resolver su problema con ensamblajes / referencias faltantes, si tiene cambios importantes en su base de código (es decir, eliminar páginas viejas, cambios en formularios, etc.), el uso de este método podría resultar en una "molestia" para cualquier usuario que inicie un proceso antes del cambio y lo complete después del cambio (es decir, solicite una página antes de cambiar, empiece a completarla) , y luego envíe la página después de cambiar al nuevo directorio).

Sé que no quieres que diga esto, pero sin un equilibrador de carga con Sticky-Sessions habilitado, no podrás permitir que las personas sigan usando la versión anterior del sitio hasta que hayan terminado mientras manejaban nuevas sesiones sobre la nueva versión: al cambiar el directorio de inicio de la aplicación, IIS realizará una nueva compilación de la aplicación y reiniciará los procesos. De esta forma puede configurar el servidor anterior para que siga atendiendo sus conexiones actuales, pero dígale a la balanza de carga que no le envíe ninguna conexión nueva.

Sin embargo, hay otro paso que puede tomar para ayudar a mitigar los problemas que a menudo se ven al respecto:

Configure MachineKey para que sea un valor constante en lugar de AutoGenerate : esto significa que cuando la AppPool se recicla, usará la misma clave y podrá descifrar las cookies de sesión, viewstate, etc.