Tuning VMs For Industrial Applications

Virtual machines are used at every level because of the value they provide in development, testing, backup, and recovery. But just because a general IT template works out of the box, does not mean it is tuned properly for your Industrial Applications.

For simplicity, we’re going to focus on the main three resources we typically have control over whether our VMs are deployed on our engineering laptops, dedicated server, or placed onto an enterprise cluster: CPU, RAM, and Disk Storage.

The rule of thumb for CPU is to allocate enough cores to support the concurrent threads possible for your application. In a standard FT View SCADA, you’d be looking at a minimum of 3 cores to cover the OS, SCADA, and I/O server. To check if you’ve saturated a core or view the head space, you’ll need more than the task-manager performance monitor. On that same screen, hit the Resource Monitor. You’ll be able to see the total loading broken down by core and process.

RAM is a bit trickier. You want as much of each application in memory as to not suffer a performance penalty for reaching out to the disk, but you need to balance that with the shared host resources. If you’ve started with the applications recommended memory, verify you’re keeping the memory use in the sweet spot of about 70-80% at nominal running. Be mindful of page faults/misses. If they start climbing your threads can be stalled as the data is read from disk. May be an indication to allocate additional memory.

A VM’s storage is the most dependent on the architecture it is deployed. A laptop, for instance, you have a fixed access speed and volume size. For servers and clusters, you have volumes that are on fast disks with low network latency and slow media for large archival that is in high latency cloud storage. For these, you’ll have to consider creating multiple volumes for your OS, applications, and archived data. Pull historical performance data an look for Page R/W a second and queue length. These are often the slowest parts of a system and responsible for lag seen by operators or remote clients.

Having these measurements and graphs, you can take them to the administrator of the system. These are values they understand and provides common ground to resolve performance issues.

This is a very broad topic and dependent on individual deployments. If you need help on your project, please reach out and we’re happy to discuss specifics.