AJapps

Performance & Disk Log Analyser for SCADA Servers

Record a Performance Monitor log on a slow SCADA server, HMI or historian and open it here: CPU, memory, disk latency, free space, network and the busiest processes are judged against stated thresholds, and memory leaks are spotted from the trend.

Log file

sample: SCADA-SRV01, antivirus scan during operation · 9 counters

GB

How to record the log

  1. and copy it to the server.
  2. In Command Prompt, in that folder, run (15 s samples for 4 hours):
typeperf -cf counters.txt -si 15 -sc 960 -f CSV -o C:\PerfLogs\scada_perf.csv

typeperf only reads counters; it changes nothing. Stop early with Ctrl+C. Open the CSV here.

Findings

11/12/2026 10:00:00.000 → 11/12/2026 10:09:45.000 (40 samples)

  • ProblemCPU above 90 % for 20 % of the samples (95th percentile 94 %). See the busiest processes below.
  • CheckProcessor queue above 8 for 33 % of the time: threads are waiting for CPU.
  • ProblemAvailable memory fell to 748 MB. Windows pages to disk and everything slows down; look for a process whose Private Bytes keep growing.
  • ProblemPhysicalDisk(0 C: D:) read latency above 50 ms for 33 % of the time (max 65 ms). The disk is too slow for the load, failing, or shared with other virtual machines.
  • CheckPhysicalDisk(0 C: D:) write latency above 20 ms for 33 % of the time (max 41 ms). The disk is too slow for the load, failing, or shared with other virtual machines.
  • CheckVolume D: has only 11.4 % of its space available. Historian, logs and Windows Update need space; a full volume stops writing.
  • Checkhistorian: private memory grew steadily from 900 MB to 1251 MB during the log — a possible memory leak. Log it over a longer period and report it to the vendor if it keeps growing.

Busiest processes (CPU, % of all cores)

MsMpEngavg 23.1 % · max 70 %
historianavg 3.4 % · max 4 %

Counters

CounterAvgP95MaxRule
Processor(_Total)\% Processor Time47.00 %94.0094.00warning > 80 %, critical > 90 % for 10 % of the time
System\Processor Queue Length3.60 threads9.009.00warning above 2 per core (8 for 4 cores)
Memory\Available MBytes1099 MB14141450warning below 1638 MB (10 % of RAM), critical below 819 MB
PhysicalDisk(0 C: D:)\Avg. Disk sec/Read26.52 ms65.0065.00warning > 20 ms, critical > 50 ms for 10 % of the time
PhysicalDisk(0 C: D:)\Avg. Disk sec/Write21.43 ms41.0041.00warning > 20 ms, critical > 50 ms for 10 % of the time
LogicalDisk(D:)\% Free Space11.61 %11.7811.80warning below 15 %, critical below 5 %
Tool guide · know before you use

What this tool is, how it works and how far to trust it

An analyser for Windows Performance Monitor logs from SCADA servers, HMIs and historians, that turns counters into a verdict on CPU, memory, disk, network and processes.

Read this before relying on a result. Every method, formula, assumption and limit is stated here, so you can check the answer yourself instead of accepting it blindly.

What it can do

  • Read CSV logs from typeperf, relog or a Data Collector Set.
  • Give min, average, maximum and 95th percentile per counter and the share of time above warning and critical levels.
  • List the busiest processes and the processes whose memory keeps growing.
  • Provide the counter list and the typeperf command to record the log.

Why you need it

  • 'Slow' has many causes; a log shows which resource is saturated and when, instead of guessing.
  • A leaking process or an antivirus scan during operation is easy to see in a log and hard to see any other way.

Understand this first

  • Short peaks are normal; what matters is how long a counter stays above its level.
  • Disk latency (seconds per read or write) shows a slow disk better than disk queue length.
  • Process CPU in Performance Monitor is per core (it can exceed 100 %); the analyser divides by the number of cores.

What you need before you start

  • A Performance Monitor log in CSV, recorded during the slow period (the page gives the counter file and the typeperf command).
  • The number of CPU cores and the installed RAM of the computer.
  • A current browser (Chrome, Edge, Firefox or Safari). Nothing is installed and your data is never uploaded; it is processed on your own computer.

How to use it

  • Download counters.txt, run the typeperf command on the server during the slow period, and copy the CSV.
  • Open the CSV and enter the cores and RAM.
  • Read the findings, then the busiest processes and the counter table.

What you get

  • Findings by area, busiest processes, memory growth and a table of every counter with its statistics and rule.

How to read the results

  • A resource above its critical level for a large share of the time is the bottleneck; fix it first.
  • If nothing exceeds its level, the delay is probably in the application or a remote server.

Technical basis

  • Rules of thumb stated with each counter: CPU above 80 / 90 %, processor queue above 2 per core, available memory below 10 % of RAM, committed memory above 80 %, disk latency above 20 / 50 ms, available disk space below 15 / 5 %, network above 70 % of the link speed.
  • Memory growth: a positive least-squares trend with at least 30 % and 100 MB growth over the log.

Limits: when not to rely on it

  • Thresholds are guidance; follow the vendor's sizing requirements where they differ.
  • Short logs can mislead; record several hours.
  • .blg files must be converted to CSV first (relog file.blg -f csv -o file.csv).

For preliminary engineering use. Results must be checked by a qualified engineer against the project's standards. How results are checked · Terms & disclaimer · Build 5da9168 · 2026-11-13