Performance monitoring tags
- Last UpdatedFeb 27, 2025
- 3 minute read
You use performance monitoring tags to monitor CPU loading and other performance parameters for various AVEVA Historian processes. (All of these values map to equivalent counters that are used in the Microsoft Performance Logs and Alerts application.)
The following tags allow you to monitor the percentage CPU load for all processors:
|
System Tag |
Description |
|---|---|
|
SysPerfAvailableBytes |
Amount of free memory (RAM). If the amount of available memory is over 4,294,967,296, then the tag shows the remainder of the amount of memory divided by 4,294,967,296. |
|
SysPerfAvailableMBytes |
Amount of free memory (RAM). Use this tag to monitor systems that have a larger amount of memory. The value for this tag is the amount of available memory divided by 1 million. |
|
SysPerfCPUMax |
The highest CPU load of any single core, expressed as a percentage (0-100). For example, on a quad core system where the current loads for each core are 25%, 40%, 60% and 10%, this tag will be "60". |
|
SysPerfCPUTotal |
The overall processor load as a percentage of all cores (0-100). |
|
SysPerfDiskTime |
Percentage of elapsed time that the disk drive was busy servicing read or write requests. |
|
SysPerfMemoryPages |
Rate at which pages are read from or written to disk to resolve hard page faults. |
The remaining system tags are used to monitor performance for each Historian service or process and for the Microsoft SQL Server service. For more information on services, see AVEVA Historian processes.
There are six system performance tags per each service or process. These tags adhere to the following naming convention:
-
SysPerf<service>CPU
-
SysPerf<service>HandleCount
-
SysPerf<service>PageFaults
-
SysPerf<service>PrivateBytes
-
SysPerf<service>PrivateMBytes
-
SysPerf<service>ThreadCount
-
SysPerf<service>VirtualBytes
-
SysPerf<service>VirtualMBytes
where <service> can be any of the following:
|
|
These tags have a cyclic storage rate of 5 seconds.
Note: The six performance tags will exist for each defined IDAS. The identifying number (N) appended to the end of the "DataAcq" portion of the tagname is the IODriverKey from the IODriver table. For example, 'SysPerfDataAcq1CPU'.
The following table describes the suffixes assigned to the names of system performance tags:
|
Suffix |
Description |
|---|---|
|
CPU |
Current percentage load on the service, expressed as a percentage of total CPU load. For example, on a quad core system, if the service is using 20% of one core, 40% of another core, and 0% of the other two cores, this tag will be 15%. |
|
HandleCount |
Total number of handles currently open by each thread in the service. A handle is a identifier for a particular resource in the system, such as a registry key or file. |
|
PageFaults |
Rate, per second, at which page faults occur in the threads executing the service. A page fault will occur if a thread refers to a virtual memory page that is not in its working set in main memory. Thus, the page will not be fetched from disk if it is on the standby list (and already in main memory) or if it is being used by another process. |
|
PrivateBytes |
Current number of bytes allocated by the service that cannot be shared with any other processes. If the amount is over 4,294,967,296, then the tag shows the remainder of the amount divided by 4,294,967,296. |
|
PrivateMBytes |
Current number of Mbytes allocated by the service that cannot be shared with any other processes. |
|
ThreadCount |
Current number of active threads in the service. A thread executes instructions, which are the basic units of execution in a processor. |
|
VirtualBytes |
Current size, in bytes, of the virtual address space that is being used by the service. If the amount is over 4,294,967,296, then the tag shows the remainder of the amount divided by 4,294,967,296. |
|
VirtualMBytes |
Current size, in Mbytes, of the virtual address space that is being used by the service. |
Important: You need to ensure that the memory that SQL Server reserves for the AVEVA Historian is adequate for the expected load. Based on your particular environment, you may need to adjust the SQL Server MemToLeave allocation. For more information on MemToLeave, see the Microsoft documentation.