Linux Gateway Performance with v8.0.12

We have a development Ignition 8.0.12 Gateway running on Linux Ubuntu.
We are using the Perspective Module for our client graphics.

In this we have conveyor tracks (using SVG paths) on which skillets are animated. Essentially the path of the svg is translated into a series of incrementing integer values and the skillets position along that path is then translated into x,y coordinates based on the path’s integer value. We have started seeing the pallets jump around on screen intermittently. I’m thinking that we need to increase resources for the Gateway in Linux, but I know very little about Linux and I am not finding any information on where to go to increase the resources.

In the Gateway’s Status/Performance page I am seeing the typical saw tooth pattern for memory usage. It maxes out at 2 GB while the VM this system is running on has been allocate 8 GB. I’d like to increase the memory the Gateway is allowed to use.

The CPU utilization is running at around 10% or below, so I’m not concerned with that aspect of the VM at present.

Can someone give me a pointer as to where the files on a Linux system live (default file locations were used during the install) and what files in this OS are relevant for adding resources to the Gateway?

Thanks.

I can’t comment on the performance issues you’re seeing, but I can point you to the ignition.conf file location from the manual:
https://docs.inductiveautomation.com/display/DOC80/Gateway+Configuration+File+Reference

Animation happens mainly on the client, so it’s unlikely the gateway memory settings are related to it (though you can still enlarge that 2GB limit if you have 8GB available, as nminchin said).

If it starts jumping around, I’d guess two animations are running simultaneously. One taking it to position A, while the other wants it at position B, and the two animations are fighting each other. Try to debug what values you set when, and check if the time difference is less than the animation duration.

In regards to the idea this is something performance related, I think you could really benefit from a view canvas. The built in transition nature of the view canvas allows you to set one move over 10s instead of having to move every 100ms, really cutting down on the calculation overhead.

You could set your transition speed to one second, and then update an output param for the skillet x/y every 1 seconds. Then bind the left/top Paramus on the skillet instance in the canvas to the x/y params on the skillet itself and that may achieve what)97 want much more efficiently.

That should also use built in CSS transforms and therefore move a bit cleaner as well. If that explanation doesn’t make sense I can mock it up and show you