Errores de acceso a OWA... el recurso HTTP esta caido!!!
Hola a tod@s!
Durante los últimos meses hemos visto muchos problemas de temas de acceso a OWA o en entornos de clúster balanceos inesperados derivados de caídas del recurso HTTP. Muchos de esos problemas han venido derivados del alto consumo de la memoria no paginada. Aquí van una serie de recomendaciones que pueden ayudar a paliar estos problemas.
Lo primero, cómo identificar el problema. La forma más sencilla para ver si el problema que estamos teniendo se corresponde con lo que os voy a contar es abrir el Administrador de Tareas y comprobar el valor de la memoria no paginada. En caso de que esté por encima de 100MB, ahí seguramente está el problema. En los siguientes enlaces podéis encontrar información sobre los tipos de memoria, límites y demás:
Memory Management - Understanding Pool Resources
https://blogs.technet.com/askperf/archive/2007/03/07/memory-management-understanding-pool-resources.aspx
Pushing the Limits of Windows: Paged and Nonpaged Pool
https://blogs.technet.com/markrussinovich/archive/2009/03/26/3211216.aspx
Ahora que ya tenemos claro algunos conceptos comentar lo siguiente:
En la mayoría de los entornos, los servidores de buzones tendrán el modificador /3GB según la recomendación. Este cambio limita la memoria no paginada a 128 MB. Cuando tenemos menos de 20MB de memoria non-paged pool el driver http.sys no acepta nuevas conexiones provocando la caída del recurso o problemas de acecso a OWA. En el caso del clúster la caída del recurso finalmente causa un balanceo inesperado. La única forma de recuperar el estado es reiniciar la máquina o en caso de que sea un clúster moviendo la instancia virtual al nodo pasivo.
Para todos los que quieran conocer la causa comentar que estos problemas suelen venir derivados por dos motivos:
- Existe algún driver, proceso, etc. que está haciendo un uso excesivo de la memoria no paginada provocando lo que se llama un "memory leak"
- Otra posible causa es que el servidor tenga una carga muy elevada alcanzando el límite de la propia máquina. En tal caso la única opción es balancear la carga con otros servidores.
Para analizar qué está consumiendo la memoria no paginada podéis seguir los pasos indicados en el siguiente artículo:
177415 How to use Memory Pool Monitor (Poolmon.exe) to troubleshoot kernel mode memory leaks
https://support.microsoft.com/default.aspx?scid=kb;EN-US;177415
En cualquier caso, si tenéis oportunidad os recomiendo abrir un incidente con el grupo de plataformas para que lo revisen.
Estas son algunas recomendaciones para intentar evitar que el problema aparezca:
Agrega la clave EnableAggressiveMemoryUsage según indica el siguiente enlace:
934878 Users receive a "The page cannot be displayed" error message, and "Connections_refused" entries are logged in the Httperr.log file on a server that is running Windows Server 2003, Exchange 2003, and IIS 6.0
https://support.microsoft.com/default.aspx?scid=kb;EN-US;934878
Verificar la versión del fichero ADF.sys. Existen problemas reportados con alguna versión por lo que es recomendable revisar si esta puede ser la causa
Deshabilita Hot-Add Memory fijando la siguiente clave:
HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management
Value: DynamicMemory
Type: REG_DWORD
Value Data: 1
Asegurar que el valor de SystemPages está fijado a 0 (Windows 2003):
HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management
Value: SystemPages
Type: REG_DWORD
Value Data: 0
En caso de tener software de Multipath y se está utilizando MPIO necesitaremos comprobar que disponemos de la versión apropiada:
961640 Nonpaged pool kernel memory leak on Windows Server 2003 with Multipathing solution installed
https://support.microsoft.com/default.aspx?scid=kb;EN-US;961640
Reducir el “open handle count” de Inetinfo:
If we cache file handles for longer durations, then the corresponding non-paged pool objects should also remain in memory (and thus, causing the NPP depletion). Decreasing the time would mean that they stay around for a shorter time and the accumulation is reduced decreasing the net non-paged pool memory usage.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\InetInfo\Parameters
FileCacheLifeTimeSeconds=dword:0000012c (300 decimal, which is 5 minutes. Default is 30 minutes)
Mover EXIFS Free List (Flst) y Auxiliary Free List (AuxL) a la memoria paginada:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EXIFS\Parameters
Set “AuxFreeListInPagedPool” = REG_DWORD 0x00000001
Set “FreeListInPagedPool” = REG_DWORD 0x00000001
Deshabilita el log de POP e IMAP en caso de que estén habilitados:
The logging feature is designed to be used for short periods of time while you gather troubleshooting information, and then turned off. If you leave protocol logging turned on, the system resources may become exhausted. If frequent bursts of traffic occur and create new log files and new handles, the server eventually runs out of non-paged pool memory and does not respond.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Pop3svc\Parameters
POP3 Protocol Log Level = 0
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IMAP4SVC\Parameters
IMAP4 Protocol Log Level = 0
Añadir también que en muchas ocasiones estos problemas han venido derivados de la aplicación del Service Pack 2 de Windows 2003. Service Pack 2 incorpora una funcionalidad llamada TPC Chimney que puede implicar problemas en servidores Exchange. Esta nueva funcionalidad permite que el procesamiento TCP sea realizado a través de la tarjeta de red. Actualmente muchos adaptadores de red no soportan dicha funcionalidad y es por esto que pueden aparecer ciertos problemas. El siguiente artículo relata una serie de problemas que pueden aparecer y la recomendación al respecto:
945977 Some problems occur after installing Windows Server 2003 SP2
https://support.microsoft.com/default.aspx?scid=kb;EN-US;945977
Windows 2003 Scalable Networking pack and its possible effects on Exchange
https://msexchangeteam.com/archive/2007/07/18/446400.aspx
Espero que esta información pueda ser de ayuda.
Saludos,
Pablo