Uso de Memória do Servidor HTML5

O Servidor HTML5 do Terminal Service Plus é executado em JAVA. Compreender como o JAVA gerencia a memória ajuda a entender o uso de memória do Servidor HTML5 do Terminal Service Plus.

Memória atribuída

Quando o Java é executado, ele tenta alocar 25% da memória física do computador. Essa memória é "atribuída", mas não utilizada diretamente - não é o uso real da memória que se pode ver no Gerenciador de Tarefas do Windows.

plataforma JAVA: 32 bits vs 64 bits

Há uma grande diferença entre essas duas plataformas:

JAVA 32 bits não pode lidar com mais de 4GB de RAM por definição. Como alocará 25% de toda a memória disponível, alocará no máximo 1GB, assumindo que há 4GB de memória física. Se houver apenas 2GB de memória física, alocará apenas 500MB, etc.
JAVA 64-bit pode lidar com muito mais do que 4GB (teoricamente até 16 exa bytes), então a memória alocada dependerá apenas da memória física.

Gerenciamento de Memória JAVA

JAVA é uma "máquina virtual". Isso significa que o JAVA gerencia a memória por conta própria. Uma vez que o JAVA aloca alguma memória, mesmo quando não precisa mais dela, não a devolverá automaticamente ao sistema. Isso é por razões de desempenho, já que alocar e desalocar memória são tarefas que consomem muitos recursos da CPU.

JAVA geralmente aguardará até ter um grande bloco de memória não utilizada antes de devolvê-lo ao sistema. O tamanho desse grande bloco depende diretamente do tamanho da memória física do computador. Quanto mais memória física em um computador, mais memória é alocada pelo JAVA.

Uso de Memória do Servidor HTML5 do Terminal Service Plus

Todos esses detalhes técnicos são a razão pela qual se pode abrir o Gerenciador de Tarefas do Windows e pensar que o TSplus HTML5 Server usa muita memória, ou que o JAVA de 32 bits usa menos memória do que o JAVA de 64 bits.

Na verdade, a memória realmente utilizada pelo TSplus HTML5 Server está diretamente relacionada ao número de sessões HTML5 abertas. Quanto mais memória disponível no computador, mais sessões HTML5 você pode abrir.

Uso de Memória da Sessão HTML5

A memória utilizada por uma sessão HTML5 depende das atividades do usuário (aplicativos e programas utilizados, Word/Excel versus programas que exigem mais recursos gráficos) e do método de conectividade estabelecido entre o servidor HTML5 do Terminal Service Plus e o computador cliente.

No caso de uso geral, uma sessão HTML5 usará 30 MB de memória (uso padrão, conectividade de websockets binários). No pior cenário, uma sessão usará até 100 MB de memória (uso intensivo, conectividade de fallback “XHR” para navegadores mais antigos).

Perda de escuta do servidor HTTP e HTTPS

Cada log de erro Java indica memória nativa suficiente para operação.

O problema é na verdade bastante simples.
Quando a sessão HTML5 começa, há memória suficiente de acordo com os valores reportados.
Então, dentro da sessão RDP, ele inicia um programa desconhecido e rouba toda a memória nativa para si.

Quando o Java o solicita novamente, ele de repente não está mais disponível, causando este erro de memória insuficiente.

Não há memória suficiente para o ambiente de execução Java continuar.
Falha na alocação de memória nativa (mmap) ao mapear 234881024 bytes. Detalhes do erro: espaço virtual G1# Possíveis razões:
O sistema ficou sem RAM física ou espaço de swap# Este processo está sendo executado com Compressed Oops habilitado, e o heap Java pode estar bloqueando o crescimento do heap nativo

Soluções possíveis:

Reduza a carga de memória no sistema
Aumente a memória física ou o espaço de troca# Verifique se o armazenamento de suporte de troca está cheio
Reduza o tamanho do heap Java (-Xmx/-Xms)
Diminuir o número de threads Java # Diminuir o tamanho da pilha de threads Java (-Xss)
Defina um cache de código maior com -XX:ReservedCodeCacheSize=

A JVM está sendo executada no modo Zero Based Compressed Oops, no qual o heap Java é colocado no primeiro espaço de endereço de 32 GB. O endereço base do heap Java é o limite máximo para o crescimento do heap nativo.
Por favor, use -XX:HeapBaseMinAddress

Potencialmente, você poderia alocar mais memória nativa para o Java desde o início e forçá-lo a parar de devolver memória ao sistema, assim alocando-a para si mesmo.
No entanto, neste caso, você encontrará o seguinte problema: programas em execução em uma sessão RDP podem ficar sem memória, e todo o sistema pode travar.

Mas você ainda pode tentar.

Abra e edite o seguinte arquivo com o Bloco de Notas: *\Clients\webserver\runwebserver.ini
Lá, você encontrará as seguintes configurações de linha de comando, como esta:

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

Remova toda a linha do runwebserver.ini e adicione o seguinte em seu 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 o servidor HTML5 via a interface gráfica do AdminTool para aplicar as alterações.
Mas antes de fazer isso, certifique-se de que o arquivo web server\runwebserver.bat não tenha um atributo somente leitura definido em suas propriedades. Caso contrário, a interface gráfica do AdminTool não conseguirá adaptar runwebserver.bat após uma reinicialização.

Na maioria dos casos, isso deve ser suficiente. Uma vez que o Java usa memória, ele a alocará para outros usos em vez de devolvê-la ao sistema. Portanto, o uso de memória do html5service.exe pode potencialmente atingir 70% da memória disponível do sistema. Nesse caso, o Java deve potencialmente parar de travar. No entanto, se outro programa estiver consumindo uma grande quantidade de memória, ele pode travar em vez disso. Nesse caso, somos impotentes; você deve garantir que haja memória suficiente para executar um servidor Java HTML, bem como outros programas.

Há uma opção no Java chamada -XX:+AggressiveHeap que pode melhorar a alocação de memória para a própria Máquina Virtual Java e, portanto, o conteúdo final de *\webserver\runwebserver.ini.

Pode parecer algo assim:

-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