Hii,
In one of our sites, Zulu Platform 64 Architecture is consuming too much CPU Usage and Memory space.
The server RAM is 8GB. We have set Gateway memory settings to 2GB. we find Zulu using too much CPU usage.
If we increase the Gateway memory(Heap size) to 4 GB also we find the similar behavior in CPU usage.
This is a EAM Server.
Can you help us with a solution?
Would increasing Server RAM solve the purpose?
Hi,
In one of our server, Zulu platform is consuming too much space.
The Gateway memory configured is 2GB. and Server RAM is 8GB.
The server is EAM server.
Can you help us with a solution to reduce the Zulu space consumption.
Can increasing the Server RAM to 16GB reduce the %CPU utilization by Zulu Platform.
A "healthy" quantity of RAM for Ignition yields a sawtooth pattern on the gateway's memory trend (gateway status => Performance) where the regular drop-offs end up somewhat below 50% and the GC event at each peak, typically around 90%, doesn't create a "Clock Drift" warning.
If your trend already looks like this, or better, then more RAM will not help your CPU utilization. If your memory trend is not dropping below 50% after the large peaks, then you might be helped by more RAM.
Show a screenshot of your Performance page.
Also, if your gateway is running anything other than Ignition (like your DB), you should migrate those services to other hardware.
While 8gb is fairly low I don't think it will make a huge difference.
What is the server physical hardware?
If it's only given 2gB, and constantly at or near that threshold, your CPU usage will redline as the garbage collector constantly runs, trying to maintain your desired maximum RAM. If this is the only thing on this VM/server/whatever (highly recommended), give it more than 1/4 of the available slice of memory. Windows consumes more resources than a 'server' OS really needs to, but you don't need to give it 6gB when your actual application only gets 2.
Hmm. I missed the double post on this somehow. I answered over here up above, now:
Thanks, Paul. Didn't occur to me to move these.
So a vm with 2 cores. Can you double the cores?
Also, do you know for sure how the host is setup? That resources are dedicated to this machine? It's important with Ignition to have resources dedicated not shared amongst multiple vms on a host.
Can you also post a screen shot of the performance graph from the gateway webpage? That's is more useful than windows performance graph.
That's the problem. CPU is over taxed. That processor has 20 cores, and you've only allocated 2 to the VM. As @bschroeder pointed out, if there are a lot of things running on that host, dedicate/reserve the resources for that host so they're not shared. If this is Hyper-V I have no idea how that's done (I'm a VMware guy and maybe a ProxMox guy now that VMware has gone subscription), but usually there's a way.
That is not the performance page I asked for. Show us the performance page from within the Ignition gateway web interface. It will have both CPU and RAM trends.
Hi,
I find the store and forward activity Unavailable. I am also getting a error in Logs "Error storing Tag History Data".When i expand the error i see "unable to add data to memory buffer. Buffer full".
Can you please help me.
the gateway memory configured is 2Gb and consumption peaks upto 1.65GB.
Can i increase the Gateway Memory?
Would a Gateway service restart help resolve the issue?
Regards,
Edwin
Hi Edwin,
This support ticket article will show you how to increase the gateway memory.
@Edwin.c, please stop making new forum topics for what is ultimately the same issue. Keep your posts in this one topic.
Ok. That performance trend suggests that your allocations are almost OK. Try giving your gateway 3G and run it for a few hours. Post the new performance chart.
(Set initial and maximum heap to 3072 in ignition.conf and restart the service.)
I have increased server RAM to 16GB. Now i find Zulu consuming around 30%CPU.
That sounds more reasonable. If you think it's too much, you will need to audit your application for poorly written code and CPU-hungry configurations. There's no simple answer for that, unfortunately.
I dont know who needs to hear this in 2025 but I had this same issue and it was because I was running far too many runScript() in my expression bindings that were largely just string splicing and boolean logic and so I converted them to slightly more complicated expression bindings instead of calling entire scripts for them and it drastically decreased the CPU usage. ChatGPT was very helpful for this task.
