Java Virtual Machine (JVM)

Default settings for the Java Virtual Machine (JVM) running on Trustgrid appliances

Memory Settings

The Java Virtual Machine (JVM) is responsible for managing the memory used by the Trustgrid service on appliances. Two key parameters that control this memory management are the minimum (min) and maximum (max) memory values. These settings can be adjusted under Advanced > JVM Memory in the Trustgrid Management Portal.

  1. Minimum Memory: This is the initial memory allocation for the JVM. When the Trustgrid service starts, the JVM allocates this amount of memory right away. It’s like setting a base size for the service’s memory footprint.

  2. Maximum Memory: This is the maximum amount of memory the JVM is allowed to use. If the Trustgrid service needs more memory than the initial amount (set by Minimum), it will continue to use more up to this maximum limit.

ParameterDefaultRecommendations
Minimum512MB512MB is the recommended smallest value
Maximum1GB- The 1GB default runs reliably on appliances with as little as 2GB of total memory
- To raise it, see Suggested Maximum Memory by Total System Memory below

Suggested Maximum Memory by Total System Memory

These are starting points assuming the appliance isn’t running any containers.

Total System MemorySuggested Maximum Memory% of Total
2GB1GB (default)50%
4GB2GB50%
8GB5GB62%
16GB11GB69%
32GB22GB69%

If the appliance also runs containers, subtract the sum of all configured containers’ Memory Max limits from the suggested value above. If the result falls below 1GB, use a larger appliance instead. For sizes not listed, cap Maximum Memory at 50-70% of total system memory, trending toward the higher end on larger appliances.

A Note on G1 and the Memory Usage Chart

Diagnosing a Suspected Memory Issue

If the node is processing traffic normally and you have no other signs of trouble, leave the defaults alone. If you want to check further, look at the JVM Heap metric for one of these patterns:

  • Heap stays pinned high (above 80% of Maximum Memory) and doesn’t drop after a forced GC run. This can indicate the appliance genuinely needs more memory.
  • Heap rapidly fills and empties in a repeating sawtooth pattern. This can indicate garbage collection is running very frequently, which adds overhead.

If you see either pattern:

  1. Force a GC run and watch the heap for a few minutes afterward. A full GC reclaims off-heap allocations that build up during normal operation, so this gives you an accurate baseline instead of the inflated reading a regular, incremental collection leaves behind.
  2. If it stays pinned high, or keeps sawtoothing under normal traffic, increase Maximum Memory using the sizing guidance above.
  3. Restart the service only if the issue persists after the steps above.

Java Garbage Collection

The Java Garbage Collection system:

  • Automatically frees up memory by removing unused objects.
  • Essential for managing memory in the JVM.

Trustgrid appliances run G1 GC by default. G1 offers more predictable, shorter garbage collection pauses than the alternative Parallel GC. That matters for nodes handling live network traffic: Parallel GC’s collections are stop-the-world and can introduce latency or drop packets while they run. Unless you’re troubleshooting a specific issue, leave the Garbage Collector setting on G1.