Utilisation de la mémoire du serveur HTML5

Le serveur Terminal Service Plus HTML5 fonctionne sur JAVA. Comprendre comment JAVA gère la mémoire aide à comprendre l'utilisation de la mémoire du serveur Terminal Service Plus HTML5.

Mémoire assignée

Lorsque Java s'exécute, il essaie d'allouer 25 % de la mémoire physique de l'ordinateur. Cette mémoire est "assignée" mais pas directement utilisée - ce n'est pas l'utilisation réelle de la mémoire que l'on peut voir dans le Gestionnaire des tâches de Windows.

plateforme JAVA : 32 bits vs 64 bits

Il y a une grande différence entre ces deux plateformes :

JAVA 32 bits ne peut pas gérer plus de 4 Go de RAM par définition. Comme il allouera 25 % de toute la mémoire disponible, il allouera au maximum 1 Go, en supposant qu'il y ait 4 Go de mémoire physique. S'il n'y a que 2 Go de mémoire physique, il n'allouera que 500 Mo, etc.
JAVA 64 bits peut gérer beaucoup plus de 4 Go (théoriquement jusqu'à 16 exa octets), donc la mémoire allouée dépendra uniquement de la mémoire physique.

Gestion de la mémoire JAVA

JAVA est une "machine virtuelle". Cela signifie que JAVA gère la mémoire de manière autonome. Une fois que JAVA alloue de la mémoire, même lorsqu'elle n'en a plus besoin, elle ne la rendra pas automatiquement au système. Cela est dû à des raisons de performance, car l'allocation et la désallocation de mémoire sont des tâches intensives pour le processeur.

JAVA attend généralement d'avoir un gros morceau de mémoire inutilisée avant de le rendre au système. La taille de ce gros morceau dépend directement de la taille de la mémoire physique de l'ordinateur. Plus il y a de mémoire physique sur un ordinateur, plus de mémoire est allouée par JAVA.

Utilisation de la mémoire du serveur HTML5 de Terminal Service Plus

Tous ces détails techniques sont la raison pour laquelle on peut ouvrir le Gestionnaire des tâches Windows et penser que le serveur HTML5 de Terminal Service Plus utilise beaucoup de mémoire, ou que JAVA 32 bits utilise moins de mémoire que JAVA 64 bits.

En réalité, la mémoire réellement utilisée par le serveur HTML5 de Terminal Service Plus est directement liée au nombre de sessions HTML5 ouvertes. Plus il y a de mémoire disponible sur l'ordinateur, plus vous pouvez ouvrir de sessions HTML5.

Utilisation de la mémoire de session HTML5

La mémoire utilisée par une session HTML5 dépend des activités de l'utilisateur (applications et programmes utilisés, Word/Excel par rapport aux programmes intensifs en dessin) et de la méthode de connectivité établie entre le serveur HTML5 de Terminal Service Plus et l'ordinateur client.

Dans le cas d'utilisation général, une session HTML5 utilisera 30 Mo de mémoire (utilisation standard, connectivité websockets binaire). Dans le pire des cas, une session utilisera jusqu'à 100 Mo de mémoire (utilisation intensive, connectivité de secours "XHR" pour les anciens navigateurs).

Perte d'écoute du serveur HTTP et HTTPS

Chaque journal d'erreur Java indique une mémoire native suffisante pour le fonctionnement.

Le problème est en réalité assez simple.
Lorsque la session HTML5 démarre, il y a suffisamment de mémoire selon les valeurs rapportées.
Ensuite, dans la session RDP, il démarre un programme inconnu et vole toute la mémoire native pour lui-même.

Lorsque Java le demande à nouveau, il n'est soudainement plus disponible, ce qui entraîne cette erreur de mémoire insuffisante.

Il n'y a pas suffisamment de mémoire pour que l'environnement d'exécution Java puisse continuer.
Échec de l'allocation de mémoire native (mmap) pour mapper 234881024 octets. Détails de l'erreur : espace virtuel G1# Raisons possibles :
Le système a épuisé la RAM physique ou l'espace d'échange# Ce processus s'exécute avec Compressed Oops activé, et le tas Java peut bloquer la croissance du tas natif.

Solutions possibles :

Réduire la charge mémoire sur le système
Augmentez la mémoire physique ou l'espace d'échange# Vérifiez si le stockage de support d'échange est plein
Réduire la taille de la mémoire Java (-Xmx/-Xms)
Réduire le nombre de threads Java # Réduire la taille de la pile de threads Java (-Xss)
Définir une taille de cache de code plus grande avec -XX:ReservedCodeCacheSize=

La JVM fonctionne en mode Zero Based Compressed Oops, dans lequel le tas Java est placé dans les 32 premiers Go d'espace d'adressage. L'adresse de base du tas Java est la limite maximale pour la croissance du tas natif.
Veuillez utiliser -XX:HeapBaseMinAddress

Potentiellement, vous pourriez allouer plus de mémoire native à Java dès le départ et le forcer à ne plus renvoyer de mémoire au système, lui allouant ainsi à lui-même.
Cependant, dans ce cas, vous rencontrerez le problème suivant : les programmes s'exécutant dans une session RDP peuvent manquer de mémoire, et l'ensemble du système pourrait planter.

Mais vous pouvez toujours essayer.

Ouvrez et modifiez le fichier suivant avec Notepad : *\Clients\webserver\runwebserver.ini
Là, vous trouverez les paramètres de ligne de commande suivants, comme ceci :

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

Supprimez toute la ligne de runwebserver.ini et ajoutez ce qui suit à sa place :

-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

Redémarrez le serveur HTML5 via l'interface AdminTool pour appliquer les modifications.
Mais avant de le faire, assurez-vous que le fichier web server\runwebserver.bat n'a pas d'attribut en lecture seule défini dans ses propriétés. Sinon, l'interface graphique AdminTool ne pourra pas adapter runwebserver.bat après un redémarrage.

Dans la plupart des cas, cela devrait suffire. Une fois que Java utilise de la mémoire, il l'allouera à d'autres usages au lieu de la retourner au système. Par conséquent, l'utilisation de la mémoire de html5service.exe pourrait potentiellement atteindre 70 % de la mémoire disponible du système. Dans ce cas, Java devrait potentiellement cesser de planter. Cependant, si un autre programme consomme une grande quantité de mémoire, il pourrait planter à la place. Dans ce cas, nous sommes impuissants ; vous devez vous assurer qu'il y a suffisamment de mémoire pour faire fonctionner un serveur HTML Java ainsi que d'autres programmes.

Il existe une option dans Java appelée -XX:+AggressiveHeap qui pourrait améliorer l'allocation de mémoire pour la machine virtuelle Java elle-même, et donc le contenu final de *\webserver\runwebserver.ini.

Cela pourrait ressembler à ceci :

-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