HTML5 Server Memory Usage

Terminal Service Plus HTML5 Server runs on JAVA. Understanding how JAVA handles memory help to understand Terminal Service Plus HTML5 Server memory usage.

Assigned memory

When Java runs, it tries to allocate 25% of the computer physical memory. This memory is “assigned” but not directly used - it is not the real memory usage that one can see in Windows Task Manager.

JAVA platform: 32-bit vs 64-bit

There is one big difference between these two platforms:

JAVA 32-bit cannot handle more than 4GB of RAM by definition. Since it will allocate 25% of all available memory, it will allocate at most 1GB, assuming there is 4GB physical memory. If there is only 2GB physical memory, it will only allocate 500MB, etc.
JAVA 64-bit can handle a lot more than 4GB (theoretically up to 16 exabytes), so the allocated memory will only depend on physical memory.

JAVA Memory Management

JAVA is a “virtual machine”. It means that JAVA handles memory management on its own. Once JAVA allocates some memory, even when it does not need it anymore, it will not automatically give it back to the system. This is for performance reasons, as memory allocating and de-allocating are CPU intensive tasks.

JAVA will usually wait until it has a big chunk of unused memory before giving it back to the system. The size of this big chunk directly depends on the size of the computer physical memory. The more physical memory on a computer, the more memory is allocated by JAVA.

Terminal Service Plus HTML5 Server Memory Usage

All these technical details are the reason why one can open Windows Task Manager and think that Terminal Service Plus HTML5 Server uses a lot of memory, or that JAVA 32 bit uses less memory than JAVA 64 bit.

Actually, the memory really used by Terminal Service Plus HTML5 Server is directly related to the number of opened HTML5 sessions. The more available memory on the computer, the more HTML5 sessions you can open.

HTML5 Session Memory Usage

The memory used by an HTML5 session depend on the user activities (applications and programs used, Word/Excel versus drawing-intensive programs) and the connectivity method established between the Terminal Service Plus HTML5 Server and the client computer.

In the general use case, an HTML5 session will use 30 MB of memory (standard use, binary websockets connectivity). In the worst case, a session will use up to 100 MB of memory (intensive use, “XHR” fallback connectivity for older browsers).

Loss of HTTP and HTTPS server listening

Each Java error log indicates sufficient native memory for operation.

The problem is actually quite simple.
When the HTML5 session starts, there is enough memory according to the reported values.
Then, within the RDP session, it starts an unknown program and steals all the native memory for itself.

When Java requests it again, it is suddenly no longer available, causing this insufficient memory error.

There is insufficient memory for the Java runtime environment to continue.
Native memory allocation (mmap) failed to map 234881024 bytes. Error details: virtual space G1# Possible reasons:
The system has run out of physical RAM or swap space# This process is running with Compressed Oops enabled, and the Java heap may be blocking the growth of the native heap

Possible solutions:

Reduce the memory load on the system
Increase physical memory or swap space# Check if the swap support storage is full
Decrease the Java heap size (-Xmx/-Xms)
Decrease the number of Java threads # Decrease the Java thread stack size (-Xss)
Set a larger code cache with -XX:ReservedCodeCacheSize=

The JVM is running in Zero Based Compressed Oops mode, in which the Java heap is placed in the first 32 GB address space. The base address of the Java heap is the maximum limit for native heap growth.
Please use -XX:HeapBaseMinAddress

Potentially, you could allocate more native memory to Java from the start and force it to stop returning memory to the system, thus allocating it to itself.
However, in this case, you will encounter the following problem: programs running in an RDP session may run out of memory, and the entire system could crash.

But you can still try.

Open and edit the following file with Notepad: *\Clients\webserver\runwebserver.ini
There, you will find the following command-line settings, like this:

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

Remove the entire line from runwebserver.ini and add the following in its 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

Restart the HTML5 server via the AdminTool GUI to apply the changes.
(But before doing so, make sure that the web server\runwebserver.bat file doesn’t have a read-only attribute set in its properties. Otherwise, the AdminTool GUI won’t be able to adapt runwebserver.bat after a restart.)

In most cases, this should be sufficient. Once Java uses memory, it will allocate it to other uses instead of returning it to the system. Therefore, the memory usage of html5service.exe could potentially reach 70% of the system’s available memory. In this case, Java should potentially stop crashing. However, if another program is consuming a large amount of memory, it could crash instead. In that case, we are powerless; you must ensure that there is enough memory to run a Java HTML server as well as others. programs.

There’s an option in Java called -XX:+AggressiveHeap that could improve memory allocation for the Java Virtual Machine itself, and therefore the final content of *\webserver\runwebserver.ini.

It might look something like this:

-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