Hardware Diagnostics Checklist

CPU, memory, disk, IO and network checks for application and database hosts. Last updated August 28, 2026.

Performance incidents often look like bad SQL, slow APIs or unstable jobs. Sometimes they are host pressure: a saturated CPU, a full disk, memory pressure, slow IO or a noisy network path. This guide gives safe checks before deeper tuning.

Linux capacity snapshot

uptime
free -h
df -h
df -ih
lsblk
top -b -n 1 | head -40
ss -s

Linux IO and disk pressure

iostat -xz 1 5 2>/dev/null
vmstat 1 5
dmesg -T | grep -Ei 'error|fail|nvme|sda|disk|oom' | tail -40
du -sh /var/log /var/lib/postgresql /var/lib/mysql 2>/dev/null

Windows capacity snapshot

Get-ComputerInfo | Select-Object CsName, OsName, OsVersion, CsProcessors, CsTotalPhysicalMemory
Get-Process | Sort-Object CPU -Descending | Select-Object -First 15
Get-Volume
Get-Counter '\Processor(_Total)\% Processor Time'
Get-Counter '\Memory\Available MBytes'

Network symptoms

Symptom	Linux check	Windows check
API timeout	`curl -v`, `ss -tulpn`, DNS lookup	`Test-NetConnection`, `Resolve-DnsName`
Database refused	Port listener and firewall state	Port test and service state
Slow transfers	Interface errors, packet drops, route path	Adapter statistics and route table

When hardware affects databases

High CPU can make simple queries look expensive.
Memory pressure can force swap and make every request slower.
Disk full conditions can stop writes, logs, backups and temp files.
High IO wait can make indexes and backups appear broken.
Network drops can look like application retry bugs.

Evidence template

Host:
Time:
CPU:
Memory:
Disk free:
Inodes:
Top process:
Database service:
Network symptom:
Next action:

Do not run destructive benchmarks on production without approval. Start with read-only observation, then decide whether deeper tests are safe.