P23 – Monitor RAM SQL Server 2022 & CPU, Disk I/O Performance
PRTG P23 – PRTG Monitoring SQL Server 2022 – CPU, RAM & Disk I/O Performance
Monitoring SQL Server services and internal counters is not enough in real production environments. System-level performance such as CPU load, RAM usage, and Disk I/O directly affects SQL stability.
In this guide, you will learn how to properly Monitor RAM SQL Server, along with CPU and Disk I/O performance, using PRTG and SSH-based sensors on Linux.
We will cover:
Disk Read/Write throughput
Disk Latency and Utilization
CPU Load Average
RAM monitoring for SQL workloads
This layer ensures your SQL Server remains stable under heavy production load.
#4. Disk I/O + Disk Latency
Disk performance is one of the most critical factors for SQL Server.
Monitor:
o Disk Read/Write
o Avg. Disk Queue Length
o Disk Latency
Sensor: SSH Script Advanced
To view disk devices:
Step 1: Create Script File
🔧 Script Content
#!/bin/bash
DISK="sda"
DATA=$(iostat -dx $DISK 1 2 | awk 'NR>6')
READ=$(echo "$DATA" | awk '{sum+=$3} END {print sum}')
WRITE=$(echo "$DATA" | awk '{sum+=$4} END {print sum}')
AWAIT=$(echo "$DATA" | awk '{sum+=$10} END {print sum}')
UTIL=$(echo "$DATA" | awk '{sum+=$NF} END {print sum}')
cat <<EOF
<prtg>
<result>
<channel>Disk Read KB/s</channel>
<value>${READ:-0}</value>
<unit>Custom</unit>
<customunit>KB/s</customunit>
</result>
<result>
<channel>Disk Write KB/s</channel>
<value>${WRITE:-0}</value>
<unit>Custom</unit>
<customunit>KB/s</customunit>
</result>
<result>
<channel>Disk Latency (await)</channel>
<value>${AWAIT:-0}</value>
<unit>TimeResponse</unit>
</result>
<result>
<channel>Disk Utilization</channel>
<value>${UTIL:-0}</value>
<unit>Percent</unit>
</result>
<text>Disk I/O & Latency check OK</text>
</prtg>
EOF
exit 0🔐 Permissions & Dependencies
Grant execution permission:
Install Linux system performance monitoring tools:
sudo apt install sysstat -y
📊 Channels After Adding Sensor
| Channel | Meaning |
|---|---|
| Disk Read KB/s | SQL read throughput |
| Disk Write KB/s | SQL write throughput |
| Disk Latency (await) | Extremely important for SQL |
| Disk Utilization | Disk busy percentage |
Disk Latency is especially critical. High latency can severely degrade SQL performance even if CPU and RAM appear normal.
Test the Script
Step 2: Set Alert Thresholds
After adding the sensor in PRTG, configure thresholds based on workload characteristics.
#5. CPU for SQL
👉 Sensor: SSH Load Average v2 (NEW)
Monitor:
• Load average
o 1 minute
o 5 minutes ⭐ (most important)
o 15 minutes
📌 On Linux:
Load ≠ %CPU.
Load represents system overload level, not direct CPU percentage.
Step 1: Add Sensor
Add SSH Load Average v2 sensor to the SQL Server device.
Step 2: Set Threshold
Channel: Load Average (5 min) ⭐
Assuming a 4-core server:
| Level | Value |
|---|---|
| Warning | > 4 |
| Error | > 6 |
📌 Do not set by %
📌 5-minute average is most important
With 2 Cores Example
Assuming a 2-core server:
• Load 1.0 = uses 1 core
• Load 2.0 = uses 2 cores
• Load 0.08 = 0.08 core
👉 0.08 / 2 cores = ~4% of total CPU capacity
Understanding load average correctly prevents false alarms and misinterpretation.
#6. RAM for SQL
👉 Sensor: SSH Meminfo v2
Memory pressure directly impacts SQL Server buffer pool and performance.
Step 1: Create Sensor
Add SSH Meminfo v2 sensor to the SQL Server device.
To manually verify RAM usage:
Note: Summary VM may report total usage including cache and other memory allocations.
Step 2: Set Threshold
Configure thresholds according to your SQL memory allocation strategy.
If SQL Server is configured with max memory limits, ensure free memory remains available for OS operations.
Avoid triggering alerts due to Linux file cache unless actual memory pressure exists.
🎯 Why System-Level Monitoring Matters
When you Monitor RAM SQL Server, you are not just checking memory usage.
You are validating:
Buffer pool stability
OS resource availability
Disk subsystem responsiveness
CPU saturation risk
Combining:
Disk I/O monitoring
CPU load average
Memory tracking
Creates a complete infrastructure monitoring layer for SQL Server.
🚀 Final Thoughts
To properly monitor SQL Server 2022 in production, you must go beyond service checks.
A complete monitoring design includes:
Disk I/O & Latency
CPU Load (5 min average)
RAM utilization
Intelligent threshold configuration
With this setup, your SQL Server monitoring becomes proactive and performance-focused — ensuring stability under real production workloads.
See also related articles
P3 – Powerful Guide 2026 Monitor WAN IP with PRTG
P3 – Powerful Guide 2026 Monitor WAN IP with PRTG PRTG – P3 Monitor Internet & WAN IP Using PRTG Network Monitor Monitoring your Internet connection is critical for any business infrastructure. If your WAN connection goes down, services such as email, VPN, remote access, and cloud applications become unavailable...
Read MoreP2 – Secure PRTG Fast: Change Port PRTG & Enable SSL
P2 – Secure PRTG Fast: Change Port PRTG & Enable SSL PRTG – P2 Secure PRTG with SSL | Enable HTTPS & Change Default Port Securing your monitoring system is not optional — it is essential. In this guide, we will walk through how to secure PRTG Network Monitor by...
Read MoreP1 – Complete Install PRTG Guide for Windows 10
PRTG – P1 How to Install PRTG on Windows 10 | Initial Setup & Configuration 🚀 Install PRTG on Windows 10 – Initial Setup & Configuration (P1) If you are starting your monitoring journey, learning how to Install PRTG properly is the first critical step. In this tutorial, I will...
Read More