HTML5 Server-Speicherverbrauch

Terminal Service Plus HTML5 Server läuft auf JAVA. Das Verständnis, wie JAVA mit Speicher umgeht, hilft, die Speichernutzung des Terminal Service Plus HTML5 Servers zu verstehen.

Zugewiesener Speicher

Wenn Java ausgeführt wird, versucht es, 25 % des physischen Speichers des Computers zuzuweisen. Dieser Speicher ist "zugewiesen", wird jedoch nicht direkt verwendet - es ist nicht die tatsächliche Speichernutzung, die man im Windows-Task-Manager sehen kann.

JAVA-Plattform: 32-Bit vs 64-Bit

Es gibt einen großen Unterschied zwischen diesen beiden Plattformen:

JAVA 32-Bit kann per Definition nicht mehr als 4 GB RAM verarbeiten. Da es 25 % des gesamten verfügbaren Speichers zuweist, wird es höchstens 1 GB zuweisen, vorausgesetzt, es sind 4 GB physischer Speicher vorhanden. Wenn nur 2 GB physischer Speicher vorhanden sind, wird es nur 500 MB zuweisen, usw.
JAVA 64-Bit kann theoretisch bis zu 16 GB verarbeiten. exa Bytes), sodass der zugewiesene Speicher nur von dem physischen Speicher abhängt.

JAVA-Speicherverwaltung

JAVA ist eine „virtuelle Maschine“. Das bedeutet, dass JAVA das Speichermanagement eigenständig übernimmt. Sobald JAVA einen Teil des Speichers zugewiesen hat, wird es diesen, auch wenn er nicht mehr benötigt wird, nicht automatisch an das System zurückgeben. Dies geschieht aus Leistungsgründen, da das Zuweisen und Freigeben von Speicher CPU-intensive Aufgaben sind.

JAVA wartet normalerweise, bis es einen großen Block ungenutzten Speichers hat, bevor es ihn an das System zurückgibt. Die Größe dieses großen Blocks hängt direkt von der Größe des physischen Speichers des Computers ab. Je mehr physischer Speicher auf einem Computer vorhanden ist, desto mehr Speicher wird von JAVA zugewiesen.

Terminal Service Plus HTML5 Server-Speicherverbrauch

All diese technischen Details sind der Grund, warum man den Windows Task-Manager öffnen und denken kann, dass Terminal Service Plus HTML5 Server viel Speicher verwendet oder dass JAVA 32 Bit weniger Speicher als JAVA 64 Bit verwendet.

Tatsächlich hängt der tatsächlich von Terminal Service Plus HTML5 Server verwendete Speicher direkt von der Anzahl der geöffneten HTML5-Sitzungen ab. Je mehr verfügbarer Speicher auf dem Computer vorhanden ist, desto mehr HTML5-Sitzungen können Sie öffnen.

HTML5-Sitzungsspeicherverbrauch

Der Speicher, der von einer HTML5-Sitzung verwendet wird, hängt von den Benutzeraktivitäten (verwendete Anwendungen und Programme, Word/Excel im Vergleich zu grafikintensiven Programmen) und der Verbindungsart ab, die zwischen dem Terminal Service Plus HTML5-Server und dem Client-Computer hergestellt wird.

Im allgemeinen Anwendungsfall benötigt eine HTML5-Sitzung 30 MB Speicher (Standardnutzung, binäre Websocket-Konnektivität). Im schlimmsten Fall benötigt eine Sitzung bis zu 100 MB Speicher (intensive Nutzung, „XHR“-Fallback-Konnektivität für ältere Browser).

Verlust des HTTP- und HTTPS-Serverhörens

Jeder Java-Fehlerprotokoll zeigt ausreichend nativen Speicher für den Betrieb an.

Das Problem ist eigentlich ganz einfach.
Wenn die HTML5-Sitzung startet, ist genügend Speicher gemäß den gemeldeten Werten vorhanden.
Dann startet es innerhalb der RDP-Sitzung ein unbekanntes Programm und stiehlt den gesamten nativen Speicher für sich.

Wenn Java es erneut anfordert, ist es plötzlich nicht mehr verfügbar, was diesen Speicherfehler verursacht.

Es gibt nicht genügend Speicher für die Java-Laufzeitumgebung, um fortzufahren.
Native-Speicherzuweisung (mmap) konnte 234881024 Bytes nicht zuordnen. Fehlermeldung: virtueller Speicher G1# Mögliche Gründe:
Das System hat keinen physischen RAM oder Swap-Speicher mehr# Dieser Prozess läuft mit aktivierten komprimierten Oops, und der Java-Heap könnte das Wachstum des nativen Heaps blockieren.

Mögliche Lösungen:

Reduzieren Sie die Speicherauslastung des Systems
Erhöhen Sie den physischen Speicher oder den Swap-Speicher# Überprüfen Sie, ob der Swap-Support-Speicher voll ist
Verringern Sie die Java-Heap-Größe (-Xmx/-Xms)
Verringern Sie die Anzahl der Java-Threads # Verringern Sie die Java-Thread-Stackgröße (-Xss)
Setzen Sie einen größeren Code-Cache mit -XX:ReservedCodeCacheSize=

Die JVM läuft im Zero Based Compressed Oops-Modus, in dem der Java-Heap im ersten 32-GB-Adressraum platziert ist. Die Basisadresse des Java-Heaps ist die maximale Grenze für das Wachstum des nativen Heaps.
Bitte verwenden Sie -XX:HeapBaseMinAddress

Möglicherweise könnten Sie von Anfang an mehr nativen Speicher für Java zuweisen und es zwingen, den Speicher nicht an das System zurückzugeben, sondern ihn sich selbst zuzuweisen.
In diesem Fall werden Sie jedoch auf folgendes Problem stoßen: Programme, die in einer RDP-Sitzung ausgeführt werden, können Speicherplatz erschöpfen, und das gesamte System könnte abstürzen.

Aber du kannst es trotzdem versuchen.

Öffnen und bearbeiten Sie die folgende Datei mit Notepad: *\Clients\webserver\runwebserver.ini
Dort finden Sie die folgenden Befehlszeilen-Einstellungen, wie diese:

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

Entfernen Sie die gesamte Zeile aus runwebserver.ini und fügen Sie Folgendes an ihrer Stelle hinzu:

-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

Starten Sie den HTML5-Server über die AdminTool-GUI neu, um die Änderungen anzuwenden.
(Aber stellen Sie vorher sicher, dass die Datei webserver\runwebserver.bat in ihren Eigenschaften kein schreibgeschütztes Attribut hat. Andernfalls kann die AdminTool-GUI runwebserver.bat nach einem Neustart nicht anpassen.)

In den meisten Fällen sollte dies ausreichend sein. Sobald Java Speicher verwendet, wird es ihn für andere Zwecke zuweisen, anstatt ihn an das System zurückzugeben. Daher könnte die Speichernutzung von html5service.exe potenziell 70 % des verfügbaren Speichers des Systems erreichen. In diesem Fall sollte Java potenziell aufhören abzustürzen. Wenn jedoch ein anderes Programm eine große Menge Speicher verbraucht, könnte es stattdessen abstürzen. In diesem Fall sind wir machtlos; Sie müssen sicherstellen, dass genügend Speicher vorhanden ist, um einen Java HTML-Server sowie andere Programme auszuführen.

Es gibt eine Option in Java namens -XX:+AggressiveHeap, die die Speicherzuweisung für die Java Virtual Machine selbst verbessern könnte, und damit den endgültigen Inhalt von *\webserver\runwebserver.ini.

Es könnte ungefähr so aussehen:

-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