You can’t fix a performance problem you can’t see. Dedicated servers give you complete visibility into the hardware. You can monitor CPU utilization, memory pressure, disk I/O wait, and network throughput but only if you’ve instrumented the right metrics and set thresholds that actually matter. This guide covers the monitoring stack, the metrics worth tracking,…
What “Performance” Actually Means on a Dedicated Server
On a VPS, you’re constrained by soft limits set by the hypervisor. Dedicated servers run directly on hardware, so your performance ceiling is real. That equates to physical RAM, actual CPU cores, and the I/O throughput of your NVMe drives. That’s a significant advantage, but it also means when you hit a limit, you’re hitting actual hardware, not an artificial governor.
That distinction matters for monitoring strategy. On shared or virtualized infrastructure, a spike in CPU usage might mean a neighbor is stealing resources. On a dedicated server, a spike means your workload is genuinely demanding more than it had before. Both need attention, but for different reasons.
Core Metrics to Track
CPU Utilization and Load Average
CPU percentage alone is an incomplete picture. An 8-core server at 90% CPU could be running well if all cores are actually executing work. The problem signals are:
Load average significantly exceeding core count: A 16-core AMD EPYC 4545P server with a 1-minute load average of 40+ means processes are queuing for CPU time, not just using it. Check with uptime or cat /proc/loadavg.
CPU wait (wa) in top output: High iowait percentage means processes are blocked waiting on disk reads or writes. The CPU is actually idle, but nothing useful is happening.
Steal time on virtualized guests: Not relevant on bare metal; if you see steal time on a “dedicated” server, you’re actually on virtualized infrastructure.
Memory Pressure
RAM exhaustion is where servers most often fall over without warning. The metrics worth watching:
Available memory (not free memory): Linux aggressively caches disk data in RAM. free -m shows “free” memory as very low on healthy servers. The “available” column is what matters, it reflects how much RAM the kernel can reclaim on demand.
Swap usage: Swap use isn’t necessarily a problem, but swap utilization increasing under normal load is a red flag. Once applications start reading/writing swap, latency spikes dramatically.
OOM killer events: Check /var/log/kern.log or dmesg | grep -i oom. If the kernel is killing processes to reclaim memory, you have a capacity problem.
InMotion’s Extreme dedicated server ships with 192GB DDR5 ECC RAM. This is enough headroom that most workloads won’t approach the ceiling even under aggressive caching. The ECC component matters too: memory errors that would silently corrupt data on consumer hardware are detected and corrected automatically.
Disk I/O
NVMe SSDs have transformed disk performance, but even NVMe can become a bottleneck under write-heavy workloads. Key metrics:
iowait: From iostat -x 1, the %await column shows average time per I/O request in milliseconds. Under 5ms is healthy for NVMe. Over 20ms under normal load indicates saturation or a failing drive.
Queue depth: iostat -x 1 also shows avgqu-sz. Sustained values above 1-2 on an NVMe drive typically indicate the disk can’t keep up with the I/O rate.
Read vs write ratio: Write-heavy workloads wear SSDs faster and can saturate write buffers. Understanding your read/write mix informs both caching strategy and storage configuration.
Network Throughput and Packet Loss
Bandwidth utilization: Use iftop or nethogs to see real-time per-connection and per-process bandwidth usage.
TCP retransmits: netstat -s | grep retransmit, rising counts indicate packet loss between server and clients or upstream infrastructure.
Connection states: ss -s shows connection counts by state. Large numbers of CLOSE_WAIT connections indicate application code isn’t closing connections properly.
Monitoring Stack Options
Netdata
Netdata is the fastest way to get real-time, per-second metrics on a Linux server with minimal configuration overhead. The default agent installation pulls CPU, memory, disk, and network metrics immediately, and the per-second granularity catches spikes that minute-averaged monitoring systems miss entirely. It runs comfortably on production servers with less than 1% CPU overhead in most configurations.
For dedicated servers managed by technical teams, Netdata’s Prometheus metrics export makes it straightforward to feed data into existing Grafana dashboards.
Prometheus + Grafana
The standard open source observability stack. Prometheus scrapes metrics from exporters (node_exporter for Linux system metrics, mysqld_exporter for MySQL, etc.) on a configurable interval, typically 15 or 30 seconds. Grafana provides the dashboarding and alerting layer.
This combination requires more initial configuration than Netdata but offers significantly more flexibility for custom metrics, long-term retention, and multi-server visibility. Most production engineering teams running more than 3-4 dedicated servers standardize on this stack.
cPanel’s Resource Monitor
If your dedicated server runs cPanel/WHM, the built-in Resource Monitor provides account-level CPU and memory usage with no additional configuration. It’s coarser than Prometheus but immediately usable and particularly valuable for identifying which cPanel accounts are consuming disproportionate resources on reseller or multi-tenant configurations.
InMotion’s Premier Care bundle includes proactive monitoring from the APS team which is particularly useful during business hours when unusual resource patterns may require coordination between server-level diagnostics and application-level investigation.
Performance Tuning Based on What You Find
CPU-Bound Workloads
If CPU is the genuine constraint, options in order of impact:
Profile the application: Tools like perf top or strace -c -p <pid> identify which system calls or functions consume the most CPU. Optimization at the application level almost always outperforms hardware changes.
Check for inefficient cron jobs: crontab -l and reviewing /etc/cron.d/ frequently reveals runaway scripts that were never optimized because they “only run occasionally.” On modern servers, occasionally can mean 10 seconds of 100% CPU every 15 minutes.
PHP-FPM worker pool sizing: Misconfigured PHP-FPM pools on web servers frequently spawn more workers than available CPU, causing context-switching overhead. Match pm.max_children to your CPU core count multiplied by a reasonable concurrency factor (typically 2-4x for I/O-bound PHP applications).
Memory-Bound Workloads
Redis or Memcached for object caching: If your application queries the database for the same data repeatedly, an in-memory cache dramatically reduces both memory pressure on the database and CPU load. Redis’s persistence options mean you can cache aggressively without losing data on restart.
Tune MySQL innodb_buffer_pool_size: By default, MySQL’s InnoDB buffer pool is set to 128MB — unusable on a server with 64GB+ RAM. Set it to 70-80% of available RAM for database-heavy workloads. MySQL documentation provides the formula and configuration options.
Transparent Huge Pages: On some workloads, disabling THP (echo never > /sys/kernel/mm/transparent_hugepage/enabled) reduces memory management latency. On others, enabling it improves throughput. Test with your specific workload.
I/O-Bound Workloads
Move to NVMe if not already: The jump from SATA SSD to NVMe typically delivers 3-5x sequential throughput and significantly lower latency. InMotion’s current dedicated server lineup ships NVMe standard.
RAID configuration: RAID-1 (mirroring) provides redundancy with no write performance penalty but no read improvement on random I/O. RAID-10 doubles both read performance and redundancy cost. Match RAID level to whether you need read acceleration, write protection, or both.
Filesystem choice: XFS handles large files and high-throughput workloads better than ext4. For database servers, ext4 with noatime and data=writeback mount options closes much of the gap.
Setting Alerting Thresholds That Matter
The goal isn’t to get an alert every time CPU exceeds 80%. The goal is to get an alert before users notice a problem.
Practical thresholds for dedicated server alerting:
CPU load average exceeds 2x core count for 5+ minutes
Available memory below 10% of total for 10+ minutes
Disk I/O await exceeds 20ms for 5+ minutes
Swap usage increasing at any rate for 15+ minutes (sustained, not a brief spike)
Any disk showing SMART pre-failure warnings
InMotion Hosting’s Premier Care includes server monitoring as part of the managed service layer. For teams running their own monitoring stack, the thresholds above catch real problems while keeping alert noise low enough to act on.Related reading: Network Latency Optimization for Dedicated Servers | Server Hardening Best Practices