Identifying Noisy Neighbor Symptoms vs. Real Performance Issues

A noisy neighbor is another guest on the same physical host that consumes shared resources aggressively enough to degrade your VM's performance. The resources most commonly involved are:

• CPU time on shared physical cores
• Disk I/O bandwidth and IOPS on shared storage
• Network bandwidth on the host's NIC or uplink

On a properly provisioned hypervisor with reasonable overcommit ratios, brief contention is normal and rarely noticeable. Sustained contention that materially impacts your workload is uncommon and is something the provider should be able to verify on their side.

CPU steal time (%st or steal) is the percentage of time your virtual CPU wanted to run but the hypervisor scheduled a different guest instead. This is the closest thing to a smoking gun for CPU-side noisy neighbors.

Check it with vmstat:

vmstat 1 10

Look at the rightmost column under cpu:

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 412384  98212 1843200    0    0     8    16  142  287  3  1 95  1  0
 0  0      0 412384  98212 1843200    0    0     0     0  118  243  2  1 97  0  0

Or with mpstat for per-CPU detail:

mpstat -P ALL 1 5

Interpreting steal time

Most "noisy neighbor" reports turn out to be one of these instead.

High Load Average With Zero Steal Time

Load average measures runnable plus uninterruptible processes. If your load is high but %st is near zero, the contention is happening inside your own VM. Common causes:

• Application threads multiplying under load
• Database queries without proper indexing
• A backup or cron job running concurrently with normal traffic
• Processes stuck in D state waiting on your own disk I/O

Find the culprit:

ps -eo state,pid,cmd | grep "^D"     # Uninterruptible sleep
ps aux --sort=-%cpu | head -20        # Top CPU consumers

High I/O Wait

%wa (iowait) in top or vmstat is often misread as "the disk is slow because of other tenants." It actually means your CPU is idle waiting on I/O that your VM requested. The question is whether your workload is generating that I/O or whether the underlying storage is genuinely slow.

iostat -xz 1 10

Look at await (average wait time per I/O in milliseconds) and %util:

• await under 10ms with low %util: storage is healthy, you are not pushing it hard
• await 10–50ms with %util near 100%: your workload is saturating your allocated I/O
• await over 50ms with low %util and low queue depth: this is unusual and worth investigating

If %util is at or near 100%, you are I/O bound on your own workload, not contending with neighbors. Use iotop to find which processes are responsible:

iotop -oPa

Memory Pressure and Swapping

Slowness from swapping looks dramatic and feels like "something outside my VM is wrong." It is almost always inside.

free -h
vmstat 1 5     # Watch si and so columns

If si (swap in) and so (swap out) are nonzero during slow periods, you are out of memory. The fix is to right-size the VM, tune the application, or add a swap file as a temporary buffer. This is never a noisy neighbor issue.

Network Latency to a Specific Destination

If your VPS suddenly has high latency to one destination but not others, that is a routing or peering issue somewhere on the path, not a tenant on your hypervisor. Confirm with mtr:

mtr -rwzc 100 destination.example.com

Look for the hop where loss or latency appears. If it shows up several hops out of the RamNode network, the problem is upstream and not something a neighbor on your host can cause.

Application Slowness With Healthy System Metrics

If vmstat, iostat, and free all look fine but your application is slow, the issue is application-layer: slow database queries, lock contention, garbage collection, external API calls, or DNS resolution delays. None of these have anything to do with the hypervisor.

Run through these steps in order before assuming noisy neighbor activity.

1. Capture a Baseline of System Metrics

Install sysstat if it is not already present:

# Debian/Ubuntu
apt install sysstat

# RHEL/Rocky/AlmaLinux
dnf install sysstat

Enable data collection in /etc/default/sysstat (Debian/Ubuntu) or /etc/sysconfig/sysstat (RHEL family) and start the service. This gives you historical data to point to instead of relying on point-in-time snapshots.

Review historical CPU including steal:

sar -u ALL 1 10
sar -u -f /var/log/sysstat/saXX     # Replace XX with day of month

2. Check Steal Time First

vmstat 1 30

If steal is consistently low (under a few percent), stop looking for a noisy neighbor and look inward.

3. Identify Top Resource Consumers

top -o %CPU
top -o %MEM
iotop -oPa

Run these during the slow period, not after recovery.

4. Check for Memory Pressure

free -h
cat /proc/pressure/memory      # Kernel 4.20+ with PSI enabled
dmesg -T | grep -i "out of memory"

PSI (Pressure Stall Information) is excellent if available. Sustained "some" or "full" values above zero indicate the kernel is stalling tasks waiting for memory.

5. Check I/O Patterns

iostat -xz 1 30

Note await, r_await, w_await, and %util. If you can correlate spikes in I/O wait with specific application activity (cron jobs, backups, database checkpoints), the issue is workload-driven.

6. Check Network at the Interface Level

sar -n DEV 1 10
ss -s

Look for rxerr/s, txerr/s, and drop/s. Errors and drops at the interface level are unusual and worth reporting. Saturated bandwidth on your end is not a noisy neighbor issue, it is sizing.

7. Correlate With Your Own Activity

The single most useful question: what changed? A new deployment, a cron job, a traffic spike, a database migration, a logging configuration change. Most performance regressions have a local cause that lines up with a recent change.

journalctl --since "1 hour ago" | less
last reboot
ls -lt /var/log/                   # Recently modified logs

Open a ticket when you have:

• Sustained steal time above 10% for at least 15 minutes with timestamps and a vmstat or sar capture
• Disk latency (await) consistently above 50ms with %util well below 100% and low queue depth, indicating the storage layer is responding slowly to light I/O
• Network errors or drops at the interface level (sar -n EDEV shows nonzero error counters)
• Performance characteristics that change abruptly with no corresponding change on your side, especially if reproducible

What to include in the ticket

• The VPS hostname or IP
• Exact timestamps with timezone (UTC preferred)
• Raw output of vmstat 1 30, mpstat -P ALL 1 10, and iostat -xz 1 30 captured during the issue
• A brief description of what your workload was doing at the time
• What you have already ruled out

Before blaming the hypervisor, ask three questions in this order:

1. Is steal time elevated? If no, the cause is inside the VM.
2. Is the VM's own resource usage near its limit? If yes, the cause is workload or sizing.
3. Did something change recently? If yes, that is almost certainly the cause.

Only after working through these should noisy neighbor activity be the leading hypothesis. In practice, the answer to one of those three questions explains the vast majority of performance complaints, and the remainder split between genuine hardware issues, network path problems, and actual hypervisor contention.

• Diagnosing High CPU Usage — top, htop, load averages, and common culprits
• Performance Optimization — right-sizing CPU, RAM, and disk allocations
• Basic Resource Monitoring — Prometheus, node_exporter, and PSI-based alerts
• Network Troubleshooting Toolkit — mtr, ss, tcpdump, and path diagnostics