Optimize Your Configuration

Reading and storing a large amount of I/O process data can require significant computer resources, especially when you have multiple redundant servers. The following describes several ways that you can reduce bandwidth and network traffic on your system.

SSD drives:

Faster disk writes mean that data is less likely to be queued up, waiting to be written to the hard drive. A large queue can slow the rest of the system.

Do initial data storage on the current server, using a separate drive if possible.

Rely on backup servers for remote storage of data. By initially saving data on the designated current server, your data is not at risk of network bottlenecks or interruptions.

For systems that support a second local drive, the benefits of storing data on a device other than the one used by the operating system include:

  • Ease of upgrading to larger storage if required.
  • Improved speed because the drive can be used in parallel rather than competing with the operating system for access to the same drive.
  • Protection of your data in the event that the operating system becomes corrupted, requiring a re-installation or reformatting of the OS drive.

Poll rate:

Do not set your scan rates to poll more frequently than required. For example, if you need data only every five minutes, it would be a mistake to leave all scan intervals (or poll rates for those using the Polling driver) at the default value of 1 second. Reading data, saving to the Historian, and synchronizing those values across servers and workstations more often than necessary can cause a significant amount of network traffic for no useful purpose.

Deadbands on reading and logging

Set within I/O tags (and legacy Analog Status tags). If values are changing by tiny amounts very quickly, good deadbands will filter the data so not every change is read or is logged to disk. Every time a value is logged, it must also be copied to all of the redundant historians. But use care not to set the deadband so large as to miss important data. Defaults are set for you on both the read and the logging deadband, but you must always check whether those values are appropriate.

Anti-virus configuration:

Most anti-virus programs want to read each file that is accessed before allowing another program to write to it. If VTScada is logging hundreds of data points per second, and the anti-virus software is trying to scan each individual file before it will allow the write, then they are unlikely to keep up, making it appear that VTScada is slow or even causing an out-of-memory error if the queue size becomes too large.

Trihedral recommends setting an exclusion so that the Data directory in the application folder is not scanned, either on demand or on full system scans. The full system scan is more of an issue because it will prevent file access while a file is being scanned, stopping writes temporarily.

Turn off folder indexing:

Trihedral also recommends that you use the Windows advanced options of the application's Data folder to turn off indexing, thereby speeding up writes. The steps follow, although this may require administrator privileges at some sites.

  1. Using the Windows file manager (not VTScada!), navigate to the application's Data folder.
  2. Right-click on the folder and select Properties.
  3. On the General tab, select Advanced.
  4. Deselect the option, "Allow files in this folder to have contents indexed...".