For the Ignition V7.8.2 Gateway, raise the Java heap maximum only as far as measured demand requires, then restart the Gateway through the Gateway Control Utility to load the changed ignition.conf. A VM with 16 GB available does not mean the Gateway should receive all 16 GB; the host also needs memory for Windows, MySQL, and other processes.
Which memory boundary does the Gateway use?
The request path is straightforward: the Gateway runs in a Java process, the Java heap maximum limits the heap that process can use, and the operating system supplies physical memory to all processes sharing the VM. The heap minimum and maximum serve different roles. The minimum sets the initial heap allocation; the maximum sets the upper bound the heap can grow toward.
Raising both values is not automatically necessary. The configuration question is not whether the minimum and maximum should match, but whether the current heap ceiling is too low for the Gateway's measured workload. Increasing the maximum gives Java more room to grow; increasing the minimum reserves more memory from startup. Change the minimum only when a measured startup or workload need justifies it.
The reported Gateway begins with 1 GB allocated while its VM has 16 GB available. Those two values describe different resource boundaries. The 16 GB is shared host capacity, not a recommended heap size. The database workload and operating system remain consumers of that capacity.
| Setting or resource | What it controls | Commissioning decision |
|---|---|---|
| Java Heap Min | Initial heap allocation | Do not raise solely because the maximum is changing. |
| Java Heap Max | Heap growth ceiling | Adjust against observed Gateway demand and shared host headroom. |
| VM available memory | Capacity shared by Gateway, MySQL, operating system, and other processes | Keep enough capacity for every co-resident workload; do not assign the entire amount to Java. |
Check: Record the present minimum and maximum values, confirm the active Gateway version is V7.8.2, and identify the other processes using the VM before editing the heap ceiling.
How much heap should the Gateway receive?
There is no universal maximum derived from the VM's 16 GB figure. One operational recommendation in the evidence is to raise only the maximum to either 3072 or 4096, and the same operator reports not needing more than 4 GB for that Gateway. Those are workload-specific examples, not limits for every installation. Another Gateway has 22 GB available and was assigned 16 GB, while its observed use was 3.3 GB. That example illustrates that an assigned heap can substantially exceed observed usage; it is not proof that the same allocation is appropriate here.
Size the maximum from measured demand over representative operation. Graph Gateway memory over several days and observe the recurring sawtooth: the heap rises as objects are allocated, then falls when garbage collection reclaims memory. Look at the low point, high point, and trend, not just a single reading. If use approaches the current ceiling during normal load, investigate whether the Gateway needs more heap. If usage consistently remains far below a proposed ceiling, assigning that much memory has no demonstrated benefit.
A suggested heuristic is for the sawtooth minimum to remain at or below 30% of the heap and the maximum to remain at or below 80%. Treat those percentages as monitoring guidance, not a guaranteed sizing rule or a universal product requirement. Re-evaluate after changing the heap: a larger heap can alter the sawtooth, so a pre-change graph does not establish post-change behavior.
Leave headroom for the rest of the VM. On a shared host, include MySQL and the operating system in the capacity decision. If memory pressure causes Windows to page out application memory, Java cleanup pauses can become more disruptive. Do not size the Gateway in isolation from the database simply because the VM has spare capacity at one moment.
Check: Capture several days of Gateway memory data under representative activity and document the observed minimum, maximum, and host memory pressure before selecting a new maximum.
What do the memory trend and pauses indicate?
| Observation | Likely interpretation | Next check |
|---|---|---|
| Heap rises and falls in a repeating sawtooth | Allocation and garbage collection are occurring; the pattern helps distinguish normal cycling from a ceiling problem. | Compare the cycle's high point with the configured maximum over multiple days. |
| High point repeatedly nears the maximum | The configured ceiling may constrain the workload, or demand may be increasing. | Review representative load and trend the heap before raising the maximum. |
| Large drop follows a long rise, with a visible Gateway pause | A larger cleanup event can pause Java threads while memory is reclaimed. | Correlate pauses with heap trends and check whether the VM is paging. |
| Gateway and MySQL compete for memory | Both are memory-intensive workloads on a shared host; raising the Gateway heap can reduce memory available to MySQL and the OS. | Monitor host memory and database behavior alongside Gateway usage. |
| Memory grows gradually across days or weeks | A single snapshot can miss periodic cleanup or slow buildup. | Keep a multi-day graph and compare the pattern after configuration changes. |
Java garbage collection reclaims objects that the application no longer uses. Collection timing and pause behavior depend on the JVM's collector and workload. The field report describes CMS cleanup as capable of producing a stop-the-world pause when difficult-to-reclaim objects are collected, particularly when substantial memory has been paged to disk; it also describes G1GC as collecting in smaller batches with more frequent, shorter pauses. The active collector and JVM behavior must be read from the actual runtime configuration rather than inferred from heap size alone.
A pause that makes the Gateway appear unresponsive is not, by itself, proof that the heap maximum is too low. Correlate the time of the pause with the memory graph, configured ceiling, and host paging or contention. A large heap can allow a larger amount of memory to accumulate before collection and can make a subsequent cleanup pause larger. Too little heap can also constrain a workload. The goal is a measured, reasonable allocation, not the largest permitted number.
Check: Before changing the heap, establish whether the observed condition is repeated ceiling pressure, a large collection pause, or host-level memory contention; the remedy depends on which signal appears.
How should the shared MySQL host affect the setting?
When Ignition and MySQL run on the same VM, their memory allocations do not operate as isolated pools unless resource controls impose a boundary. Raising the Java maximum does not directly command MySQL to release memory, but both processes compete for the host's physical memory. If total demand exceeds capacity, the operating system must manage the pressure, which can lead to paging and poorer response from either application.
CPU isolation, such as cgroups or another resource-isolation mechanism, addresses CPU contention; it does not by itself solve memory contention. A separate VM can provide stronger workload separation, but it does not create physical memory capacity where none exists. For the current shared machine, monitor both Gateway heap behavior and host memory pressure, and check MySQL operation after each change.
Do not use Gateway heap utilization as the only signal. Java can occupy memory differently from total process and host usage, and a low Gateway heap reading does not prove the VM has ample memory for its other workloads. Compare the Gateway trend with operating-system memory and paging indicators, plus database health.
Check: Confirm that the VM retains headroom under simultaneous Gateway and MySQL activity, not only during a quiet period, before committing to the proposed heap maximum.
How do you change and load the heap configuration?
- Open the Gateway's
ignition.confand locate the Java Heap Min and Java Heap Max settings. Record the current values so you can restore them if the result degrades. - Choose a revised maximum based on the multi-day trend and shared-host headroom. Values of 3072 or 4096 were used as examples in one installation; treat them as candidate values only when they fit the measured demand and VM capacity.
- Leave the minimum unchanged unless a separate measurement supports changing the initial allocation. Avoid changing both settings at once when the issue is only that the maximum may be too low; a single-variable change makes the result easier to assess.
- Save the configuration change, then restart the Gateway from the Gateway Control Utility. A restart is required to load the new
ignition.confsettings; monitoring alone does not apply the change. - After restart, confirm the Gateway is running and the intended heap settings are active. Recheck the memory graph and VM-level memory use under normal and peak activity.
Check: The Gateway restarts successfully, reports the intended heap configuration, and shows no new host memory pressure during representative workload.
How do you verify the change over time?
Use the Gateway status page to monitor Gateway memory usage; where available, the Gateway memory profiler provides more detailed tracking. The evidence identifies the profiler as available beginning with Ignition 7.9, so it does not apply to the stated V7.8.2 installation. For V7.8.2, use the status page and operating-system monitoring rather than assuming that later-version profiler features exist.
Compare the post-change sawtooth against the baseline: note the minimum, peak, frequency of large drops, and whether peaks still approach the maximum. Check that increased Gateway allocation has not pushed MySQL or the operating system into memory pressure. If the Gateway no longer approaches the cap but host memory becomes constrained, reduce the maximum and reassess; if the Gateway still reaches the cap under normal load while the host retains headroom, a further measured adjustment may be warranted.
A successful change is not just a larger configured number. It is a Gateway that completes normal operation without recurring ceiling pressure or disruptive pauses, while the shared VM continues to support MySQL and the operating system without paging-driven contention. Maintain the graph long enough to capture the workload cycle; memory cleanup events can be separated by days or weeks.
Check: After representative operation, compare the multi-day Gateway trend and host memory indicators with the baseline, then retain the new maximum only if heap pressure falls without creating MySQL or system memory contention.
What should you check before raising Ignition heap memory?
These answers apply to the configuration and monitoring decisions above.
What happens if I increase only the Java Heap Max?
The Gateway can grow its heap to a higher ceiling, while its initial allocation remains unchanged. Restart the Gateway through the Gateway Control Utility for the changed ignition.conf setting to take effect.
What happens if I set the Gateway maximum to 4 GB?
A 4096 setting was used as an example, but it is not a universal limit or recommendation. Compare the candidate value with multi-day Gateway usage and available VM headroom, including memory used by MySQL and the operating system.
What happens if the Gateway uses less memory than its assigned maximum?
An unused ceiling does not demonstrate a need to allocate that much heap. Track the sawtooth minimum and peak over several days, and avoid raising the maximum without a measured workload requirement.
What happens if the Gateway memory graph improves after restart?
Verify the Gateway and MySQL under representative simultaneous load, confirm host memory and paging remain acceptable, then compare the post-change multi-day sawtooth with the baseline before retaining the new maximum.