El misterio de la falta de memoria en Notes 11

Algunos de nuestros clientes que actualizaron a Notes 11 experimentaron errores de falta de memoria en el cliente de Notes.

A veces era un cuadro de mensaje que decía que no hay suficiente memoria libre, a veces era un bloqueo con errores en el registro de seguimiento. Por lo general, sucedía después de que el cliente había estado abierto durante un tiempo y, a menudo, al abrir correos electrónicos MIME que se enviaban desde Internet o al hacer clic en enlaces para abrir un navegador externo. Si los usuarios habían iniciado sesión en Sametime, era más probable que sucediera.

Lo raro de esto:

¿Qué diablos estaba pasando y qué podemos hacer para solucionarlo?

La primera pista es que el Administrador de tareas solo muestra el conjunto de trabajo memoria para una aplicación: esencialmente la cantidad de memoria en uso. Ese es un buen número para saber, y en la mayoría de los casos ese es el número que es importante, pero hay otras formas en que puede quedarse sin memoria. Abrimos Windows Performance Monitor para echar un vistazo más de cerca.

Performance Monitor tiene una sección de Procesos con medidas de memoria adicionales que puede rastrear. Específicamente, analizamos los "Bytes privados" (la cantidad de comprometido memoria que utiliza la aplicación) y "Bytes virtuales" (la cantidad de espacio de direcciones virtuales la aplicación ha reservado). Aquí hay una captura de pantalla del Monitor de rendimiento y el Administrador de tareas uno al lado del otro mientras se ejecuta el cliente de Notes:

Puede ver que mientras el Administrador de tareas muestra 215 MB de memoria en uso, el Monitor de rendimiento nos dice que hay se reservan casi 2 GB de espacio de direcciones virtuales. Cuando estábamos probando, descubrimos que se estaban produciendo errores de falta de memoria en el punto en que el cliente alcanzó la marca de 2 GB en el monitor de espacio de direcciones virtuales.

Esta marca de 2 GB es importante porque el cliente de Notes sigue siendo una aplicación de 32 bits. Uno de los efectos secundarios de esto es que solo tiene 2 GB de espacio de direcciones virtuales para jugar (en realidad 4 GB, pero la mitad lo reclama el núcleo). Las aplicaciones de 64 bits tienen un espacio de direcciones virtuales mucho más grande (a veces reservan terabytes de espacio), pero las aplicaciones de 32 bits deben tener cuidado.

BARRA LATERAL: algunas aclaraciones sobre el espacio de direcciones virtuales:

Aparte de eso, es un poco difícil de explicar, y a la mayoría de la gente no le importa, pero si te interesa, este es un buen resumen: https://docs.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/virtual-address-spaces

De todos modos, sabiendo lo que sabemos, ¿por qué se usa tanto y cómo podemos solucionar el problema?

Alerta de spoiler: la solución inmediata fue reducir el tamaño de almacenamiento dinámico de Java utilizado por el cliente de Notes. Esto parece contrario a la intuición: normalmente, cuando tiene un error de falta de memoria, desea aumentar la memoria, pero siga leyendo.

El tamaño del almacenamiento dinámico de Java para el cliente está controlado por un parámetro en el archivo jvm.properties, en el Directorio Notes/framework/rcp/deploy. Tiene una entrada como esta:

vmarg.Xmx=-Xmx512m

Esto controla el tamaño máximo del almacenamiento dinámico de Java, que es la cantidad de memoria que utiliza Java (y en este caso el cliente de Notes) para ejecutar el código. El valor predeterminado para Notes es 512 MB, como se muestra en el parámetro anterior. Sin embargo, a muchos clientes les gusta aumentar esto si están haciendo cosas que requieren mucha memoria con sus clientes de Notes, especialmente si están usando Domino Designer.

Este es un parámetro bastante común para ajustar, e incluso hay una nota técnica sobre cómo cambiarlo. esta página.

Nuestros clientes a los que se les estaban acabando los errores de memoria tenían este parámetro establecido en 1024 MB. Esto nunca fue un problema con Notes 9, pero de repente con Notes 11 era demasiada memoria para asignar al montón.

Al reducir esto a Xmx512m, los errores de falta de memoria desaparecieron.

También pudimos confirmar en el Monitor de rendimiento que el uso de un montón de 512 MB redujo el espacio de direcciones virtuales a aproximadamente 1.5 GB, lo que le dio al cliente mucho más espacio para respirar cuando necesitaba reservar algunos espacios adicionales.

La siguiente pregunta obvia es: ¿por qué los clientes no tuvieron este problema con el cliente de Notes 9?

Cuando compila una aplicación de 32 bits, hay un indicador que puede configurar llamado /LARGEADDRESSAWARE. Esto permite que el proceso de la aplicación use 4 GB completos de espacio de direcciones virtuales en un sistema operativo de 64 bits, en lugar de los 2 GB que estábamos viendo arriba.

Resulta que el java.exe y notas2.exe los archivos del cliente Notes 9 se compilaron con los indicadores /LARGEADDRESSAWARE, pero los archivos java.exe y notes2.exe del cliente Notes 11 no.

Notes 9 usaba la versión de IBM de Java JVM pero Notes 11 usa la versión OpenJDK OpenJ9. La distribución OpenJ9 de 32 bits no se compiló con /LARGEADDRESSAWARE hasta hace poco (versión 8u262, de junio de 2020), por lo que el cliente de Notes 11 tampoco se compiló con esa marca.

En otras palabras, Notes 9 tenía un espacio completo de direcciones virtuales de 4 GB, pero Notes 11 solo tiene 2 GB.

Hemos estado en conversaciones con HCL sobre esto, y son conscientes del problema y están planeando una solución. Ram Krishnamurthy, arquitecto jefe de la HCL Notes Cliente, nos dio esta guía:

“Este es un defecto conocido de OpenJDK para la versión 1.8 solo en Windows. El equipo de OpenJDK ha encontrado una solución para este problema y realizará una release de la solución en breve. Actualmente se está planeando incluir esta corrección en un próximo Fix Pack 1101. Esto solo afecta a las versiones basadas en v11, ya que incluye OpenJDK. Hasta entonces, se puede utilizar la solución documentada en este artículo”.

Una vez que el cliente de Notes usa una versión más nueva de OpenJ9 y HCL puede volver a agregar el indicador del compilador, este problema desaparecerá.