My V7.8.2 Gateway has only 1Gb of memory allocated. My VM hosting Ignition has 16Gb available.
I understand in the igntion.conf file are the settings to increase memory. Do I increase both the Java Heap
Min & Max settings ?
With 16Gb available is there a maximum size I should not exceed?
I also assume a Gateway reset is required to load ignition.conf new settings.
I usually just change the Max to either 3072 or 4096. I’ve never needed more than 4 gig for the gateway, but I guess it all depends on what you’re doing.
After changing just do a gateway restart from the Gateway Control Utility.
You can monitor the ram you are using from the status page of the web front end.
My Gateway has 22 Gig, I give it 16 to play with 
Just checked mine is currently using 3.3 gig.
Just a follow-up question - is there a reasonable upper limit for the % of machine’s memory you should allocate to the gateway? I’m running the historian’s database (MySQL) on the same machine, any chance it will start robbing from that?
It depends. If you are using cgroups or some other cpu resource isolation between MySQL and Ignition, it shouldn't be a problem. Most people just use a separate VM to isolate the CPUs. Both databases and complex Java apps are memory hogs, so if you don't have enough ram to begin with, you're going to have contention.
As for allocating memory for Ignition, I recommend graphing the % memory usage of Ignition over several days, to figure out its 'sawtooth' pattern. I generally suggest that the minimum of the sawtooth shouldn't be more than 30%, and the max shouldn't be more that 80%. Adding a lot more memory to Ignition will change the sawtooth pattern a bit, too, so don't just go wild. The bigger the drop after each "tooth", the bigger the "pause the world" event can be.
It’s generally best to not allow more than the maximal necessary (with a little reserve).
Java works with a garbage collection algorithm, so it doesn’t clean up memory until triggered. Under certain algorithms, like the default CMS (Concurrent Mark Sweep), the easy objects will be cleaned up regularly, but some objects are hard to clean up (objects that existed a long time before being dropped, objects with circular references to each other but no active references from the main thread anymore, etc). These objects that are hard to clean up won’t be cleaned up by the CMS until necessary.
But then, when the CMS starts to clean up those objects, it has to stop the world (put all threads in “pause” mode), until the data is cleaned again. When there are a huge amount of objects to clean up, and certainly when some of these objects have been written to the pagefile by Windows, this stop the world can make it look like Ignition crashed.
Depending on the available memory, and the speed at which the memory builds up, it can take days or weeks before a complete clean needs to happen. And when this happens if nobody is watching, it won’t be very noticeable. So it can take months to notice.
There are better garbage collection algorithms, like G1GC, this does the cleanup in smaller batches. This means you have more, but shorter pauses on your threads. And it avoids Windows writing a big amount of memory to the pagefile.
But all in all, it’s still advisable to give the JVM a reasonable amount of memory. Not too much, and not too little. If you only ever use 1 GB of memory, there’s no point in giving 16 GB to the JVM.
Since version 7.9, Ignition also has a memory profiler on the gateway page, that’s a great tool to keep track of the memory usage of the gateway and adjust the memory as needed.
Much thanks - that is exactly the insight I was looking for. Thanks!