Uso de memoria del servidor HTML5

El servidor HTML5 de Terminal Service Plus se ejecuta en JAVA. Comprender cómo JAVA maneja la memoria ayuda a entender el uso de memoria del servidor HTML5 de Terminal Service Plus.

Memoria asignada

Cuando Java se ejecuta, intenta asignar el 25% de la memoria física del ordenador. Esta memoria está "asignada" pero no se utiliza directamente; no es el uso real de la memoria que se puede ver en el Administrador de tareas de Windows.

plataforma JAVA: 32 bits vs 64 bits

Hay una gran diferencia entre estas dos plataformas:

JAVA de 32 bits no puede manejar más de 4 GB de RAM por definición. Dado que asignará el 25% de toda la memoria disponible, asignará como máximo 1 GB, asumiendo que hay 4 GB de memoria física. Si solo hay 2 GB de memoria física, solo asignará 500 MB, etc.
JAVA de 64 bits puede manejar mucho más de 4 GB (teóricamente hasta 16 exa bytes), por lo que la memoria asignada dependerá únicamente de la memoria física.

Gestión de memoria JAVA

JAVA es una "máquina virtual". Esto significa que JAVA gestiona la memoria por su cuenta. Una vez que JAVA asigna memoria, incluso cuando ya no la necesita, no la devolverá automáticamente al sistema. Esto es por razones de rendimiento, ya que la asignación y desasignación de memoria son tareas intensivas para la CPU.

JAVA generalmente esperará hasta que tenga un gran bloque de memoria no utilizada antes de devolverlo al sistema. El tamaño de este gran bloque depende directamente del tamaño de la memoria física del ordenador. Cuanta más memoria física tenga un ordenador, más memoria será asignada por JAVA.

Uso de memoria del servidor HTML5 de Terminal Service Plus

Todos estos detalles técnicos son la razón por la cual uno puede abrir el Administrador de tareas de Windows y pensar que Terminal Service Plus HTML5 Server utiliza mucha memoria, o que JAVA de 32 bits utiliza menos memoria que JAVA de 64 bits.

En realidad, la memoria realmente utilizada por el servidor HTML5 de Terminal Service Plus está directamente relacionada con el número de sesiones HTML5 abiertas. Cuanta más memoria disponible haya en la computadora, más sesiones HTML5 podrás abrir.

Uso de memoria de sesión HTML5

La memoria utilizada por una sesión HTML5 depende de las actividades del usuario (aplicaciones y programas utilizados, Word/Excel frente a programas intensivos en gráficos) y del método de conectividad establecido entre el servidor HTML5 de Terminal Service Plus y la computadora cliente.

En el caso de uso general, una sesión HTML5 utilizará 30 MB de memoria (uso estándar, conectividad de websockets binarios). En el peor de los casos, una sesión utilizará hasta 100 MB de memoria (uso intensivo, conectividad de "XHR" de respaldo para navegadores más antiguos).

Pérdida de la escucha del servidor HTTP y HTTPS

Cada registro de error de Java indica suficiente memoria nativa para la operación.

El problema es en realidad bastante simple.
Cuando comienza la sesión HTML5, hay suficiente memoria según los valores reportados.
Luego, dentro de la sesión RDP, inicia un programa desconocido y roba toda la memoria nativa para sí mismo.

Cuando Java lo solicita de nuevo, de repente ya no está disponible, causando este error de memoria insuficiente.

No hay suficiente memoria para que el entorno de ejecución de Java continúe.
La asignación de memoria nativa (mmap) no pudo mapear 234881024 bytes. Detalles del error: espacio virtual G1# Posibles razones:
El sistema se ha quedado sin RAM física o espacio de intercambio# Este proceso se está ejecutando con Compressed Oops habilitado, y el montón de Java puede estar bloqueando el crecimiento del montón nativo.

Posibles soluciones:

Reduce la carga de memoria en el sistema
Aumentar la memoria física o el espacio de intercambio# Verificar si el almacenamiento de soporte de intercambio está lleno
Disminuir el tamaño del heap de Java (-Xmx/-Xms)
Disminuir el número de hilos de Java # Disminuir el tamaño de la pila de hilos de Java (-Xss)
Establecer un caché de código más grande con -XX:ReservedCodeCacheSize=

La JVM se está ejecutando en modo Zero Based Compressed Oops, en el cual el montón de Java se coloca en el primer espacio de direcciones de 32 GB. La dirección base del montón de Java es el límite máximo para el crecimiento del montón nativo.
Por favor, use -XX:HeapBaseMinAddress

Potencialmente, podrías asignar más memoria nativa a Java desde el principio y obligarlo a dejar de devolver memoria al sistema, asignándola así a sí mismo.
Sin embargo, en este caso, te encontrarás con el siguiente problema: los programas que se ejecutan en una sesión RDP pueden quedarse sin memoria, y todo el sistema podría fallar.

Pero aún puedes intentarlo.

Abre y edita el siguiente archivo con el Bloc de notas: *\Clients\webserver\runwebserver.ini
Allí, encontrará la siguiente configuración de línea de comandos, así:

-Djdk.tls.ephemeralDHKeySize=matched -Djdk.tls.rejectClientInitiatedRenegotiation=true -Dorg.jboss.netty.epollBugWorkaround=true -XX:+UseG1GC -XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=10 ************
and so on

Elimina toda la línea de runwebserver.ini y añade lo siguiente en su lugar:

-server -javaagent:"%~dp0httpwebs.jar" -Djdk.tls.ephemeralDHKeySize=matched -Djdk.tls.rejectClientInitiatedRenegotiation=true -Dorg.jboss.netty.epollBugContourn=true --add-opens java.prefs/java.util.prefs=ALL-UNNAMED --add-opens java.base/java.lang.reflect=ALL-UNNAMED --add-opens java.base/sun.security.ssl=ALL-UNNAMED --add-opens java.base/java.nio=ALL-UNNAMED --add-opens java.base/jdk.internal.ref=ALL-UNNAMED --add-exports java.prefs/java.util.prefs=ALL-UNNAMED ---add-exports java.base/java.lang.reflect=ALL-UNNAMED --add-exports java.base/sun.security.ssl=ALL-UNNAMED --add-exports java.base/jdk.internal.ref=ALL-UNNAMED --add-exports java.base/java.nio=ALL-UNNAMED

Reinicie el servidor HTML5 a través de la interfaz gráfica de AdminTool para aplicar los cambios.
Pero antes de hacerlo, asegúrate de que el archivo web server\runwebserver.bat no tenga un atributo de solo lectura establecido en sus propiedades. De lo contrario, la interfaz gráfica de AdminTool no podrá adaptar runwebserver.bat después de un reinicio.

En la mayoría de los casos, esto debería ser suficiente. Una vez que Java utiliza memoria, la asignará a otros usos en lugar de devolverla al sistema. Por lo tanto, el uso de memoria de html5service.exe podría alcanzar potencialmente el 70% de la memoria disponible del sistema. En este caso, Java debería dejar de fallar. Sin embargo, si otro programa está consumiendo una gran cantidad de memoria, podría fallar en su lugar. En ese caso, somos impotentes; debes asegurarte de que haya suficiente memoria para ejecutar un servidor HTML de Java, así como otros programas.

Hay una opción en Java llamada -XX:+AggressiveHeap que podría mejorar la asignación de memoria para la Máquina Virtual de Java, y por lo tanto el contenido final de *\webserver\runwebserver.ini.

Podría verse algo así:

-XX:+AggressiveHeap -server -javaagent:"%~dp0httpwebs.jar" -Djdk.tls.ephemeralDHKeySize=matched -Djdk.tls.rejectClientInitiatedRenegotiation=true -Dorg.jboss.netty.epollBugWorkaround=true --add-opens java.prefs/java.util.prefs=ALL-UNNAMED --add-opens java.base/java.lang.reflect=ALL-UNNAMED --add-opens java.base/sun.security.ssl=ALL-UNNAMED --add-opens java.base/java.nio=ALL-UNNAMED --add-opens java.base/jdk.internal.ref=ALL-UNNAMED --add-exports java.prefs/ java.util.prefs=ALL-UNNAMED --add-exports java.base/java.lang.reflect=ALL-UNNAMED --add