Utilizzo della memoria del server HTML5

Il server HTML5 di Terminal Service Plus funziona su JAVA. Comprendere come JAVA gestisce la memoria aiuta a comprendere l'uso della memoria del server HTML5 di Terminal Service Plus.

Memoria assegnata

Quando Java viene eseguito, cerca di allocare il 25% della memoria fisica del computer. Questa memoria è "assegnata" ma non utilizzata direttamente - non è l'effettivo utilizzo della memoria che si può vedere nel Task Manager di Windows.

Piattaforma JAVA: 32-bit vs 64-bit

C'è una grande differenza tra queste due piattaforme:

JAVA 32-bit non può gestire più di 4GB di RAM per definizione. Poiché alloca il 25% di tutta la memoria disponibile, allocerà al massimo 1GB, assumendo che ci siano 4GB di memoria fisica. Se ci sono solo 2GB di memoria fisica, allocerà solo 500MB, ecc.
JAVA 64-bit può gestire molto più di 4GB (teoricamente fino a 16 exa byte), quindi la memoria allocata dipenderà solo dalla memoria fisica.

Gestione della memoria JAVA

JAVA è una "macchina virtuale". Significa che JAVA gestisce autonomamente la gestione della memoria. Una volta che JAVA alloca della memoria, anche quando non ne ha più bisogno, non la restituirà automaticamente al sistema. Questo è per motivi di prestazioni, poiché l'allocazione e la deallocazione della memoria sono compiti intensivi per la CPU.

JAVA di solito aspetterà fino a quando non avrà un grande blocco di memoria inutilizzata prima di restituirlo al sistema. La dimensione di questo grande blocco dipende direttamente dalla dimensione della memoria fisica del computer. Maggiore è la memoria fisica su un computer, maggiore è la memoria allocata da JAVA.

Utilizzo della memoria del server HTML5 di Terminal Service Plus

Tutti questi dettagli tecnici sono il motivo per cui si può aprire il Task Manager di Windows e pensare che il server HTML5 di Terminal Service Plus utilizzi molta memoria, o che JAVA a 32 bit utilizzi meno memoria di JAVA a 64 bit.

Attualmente, la memoria realmente utilizzata da Terminal Service Plus HTML5 Server è direttamente correlata al numero di sessioni HTML5 aperte. Maggiore è la memoria disponibile sul computer, maggiore è il numero di sessioni HTML5 che puoi aprire.

Utilizzo della memoria della sessione HTML5

La memoria utilizzata da una sessione HTML5 dipende dalle attività dell'utente (applicazioni e programmi utilizzati, Word/Excel rispetto a programmi intensivi di disegno) e dal metodo di connettività stabilito tra il server HTML5 di Terminal Service Plus e il computer client.

Nel caso d'uso generale, una sessione HTML5 utilizzerà 30 MB di memoria (uso standard, connettività websocket binari). Nel caso peggiore, una sessione utilizzerà fino a 100 MB di memoria (uso intensivo, connettività di fallback "XHR" per browser più vecchi).

Perdita di ascolto del server HTTP e HTTPS

Ogni registro di errore Java indica una memoria nativa sufficiente per il funzionamento.

Il problema è in realtà piuttosto semplice.
Quando inizia la sessione HTML5, c'è abbastanza memoria secondo i valori riportati.
Poi, all'interno della sessione RDP, avvia un programma sconosciuto e ruba tutta la memoria nativa per sé.

Quando Java lo richiede di nuovo, improvvisamente non è più disponibile, causando questo errore di memoria insufficiente.

Non c'è memoria sufficiente per l'ambiente di esecuzione Java per continuare.
Allocazione della memoria nativa (mmap) non riuscita per mappare 234881024 byte. Dettagli dell'errore: spazio virtuale G1# Possibili motivi:
Il sistema ha esaurito la RAM fisica o lo spazio di swap# Questo processo sta funzionando con Compressed Oops abilitato, e l'heap Java potrebbe bloccare la crescita dell'heap nativo

Possibili soluzioni:

Ridurre il carico di memoria sul sistema
Aumenta la memoria fisica o lo spazio di swap# Controlla se lo spazio di supporto per lo swap è pieno
Riduci la dimensione dell'heap Java (-Xmx/-Xms)
Riduci il numero di thread Java # Riduci la dimensione dello stack dei thread Java (-Xss)
Imposta una cache di codice più grande con -XX:ReservedCodeCacheSize=

La JVM è in esecuzione in modalità Zero Based Compressed Oops, in cui l'heap Java è collocato nei primi 32 GB di spazio indirizzi. L'indirizzo base dell'heap Java è il limite massimo per la crescita dell'heap nativo.
Si prega di utilizzare -XX:HeapBaseMinAddress

Potenzialmente, potresti allocare più memoria nativa a Java fin dall'inizio e costringerlo a smettere di restituire memoria al sistema, allocandola quindi a se stesso.
Tuttavia, in questo caso, si presenterà il seguente problema: i programmi in esecuzione in una sessione RDP potrebbero esaurire la memoria e l'intero sistema potrebbe bloccarsi.

Ma puoi ancora provare.

Apri e modifica il seguente file con Notepad: *\Clients\webserver\runwebserver.ini
Lì troverai le seguenti impostazioni della riga di comando, come questa:

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

Rimuovi l'intera riga da runwebserver.ini e aggiungi quanto segue al suo posto:

-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

Riavviare il server HTML5 tramite l'interfaccia grafica di AdminTool per applicare le modifiche.
(Ma prima di farlo, assicurati che il file web server\runwebserver.bat non abbia impostato un attributo di sola lettura nelle sue proprietà. Altrimenti, l'interfaccia grafica di AdminTool non sarà in grado di adattare runwebserver.bat dopo un riavvio.)

Nella maggior parte dei casi, questo dovrebbe essere sufficiente. Una volta che Java utilizza la memoria, la assegnerà ad altri usi invece di restituirla al sistema. Pertanto, l'uso della memoria di html5service.exe potrebbe potenzialmente raggiungere il 70% della memoria disponibile del sistema. In questo caso, Java dovrebbe potenzialmente smettere di bloccarsi. Tuttavia, se un altro programma sta consumando una grande quantità di memoria, potrebbe bloccarsi invece. In tal caso, siamo impotenti; devi assicurarti che ci sia abbastanza memoria per eseguire un server HTML Java così come altri programmi.

C'è un'opzione in Java chiamata -XX:+AggressiveHeap che potrebbe migliorare l'allocazione della memoria per la Java Virtual Machine stessa e, di conseguenza, il contenuto finale di *\webserver\runwebserver.ini.

Potrebbe sembrare qualcosa del genere:

-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