A full disk and a slow disk are different problems
A VPS can feel slow even when df shows plenty of free space. Capacity tells you how much data the filesystem can hold; I/O latency concerns how long read and write requests take. Repeatedly high guest-visible I/O wait can help explain the symptom, but one iowait number does not prove that a physical disk is overloaded or faulty.
Capture several read-only samples while the slowdown is happening. Compare per-device await and queue length with application response time, CPU iowait, swap activity and CPU steal. Use the readings to narrow the next question, not to choose a VM resize or storage replacement by default.
Record the symptom and a comparable time window
Write down when the slowdown began and ended, the affected site or service, the guest time zone and whether the VPS was slow for every request or only one workload. A short repeatable sample is more useful than a single value taken after the system recovered.
date -u '+%Y-%m-%dT%H:%M:%SZ'
uptime
df -hTThese commands report the current time, load and filesystem capacity; they do not change the server. If the issue is that a filesystem or inode pool is full, use the separate VPS disk-space guide. Free space does not rule out slow I/O, and high I/O wait does not mean the disk is full.
Measure the guest-visible devices with iostat
If iostat is already available, take six one-second reports during the problem:
iostat -x 1 6The first report covers activity since boot; compare the next five interval reports with the time the application was slow. In this extended report, await is the average time for I/O requests, including both queueing and service. r_await and w_await split reads and writes. aqu-sz is the average request queue length.
%util shows how much of the interval the device had I/O requests. A value near 100% can indicate saturation for a device that serves requests serially; it does not show the performance limit of devices that serve requests in parallel. Do not use a universal await or %util threshold. Compare repeated readings with the normal workload and the application's actual response time.
iostat is part of the sysstat tools and may not be installed. Do not install software on a production VPS just to obtain one reading; follow the service's change process or ask the authorised operator. Missing iostat is not evidence that storage is healthy or unhealthy.
Cross-check wait, swapping and CPU scheduling
Use vmstat for a short whole-system cross-check if it is available:
vmstat 1 6As with iostat, the first report is an average since boot; compare the following interval rows. The b column counts blocked processes, si and so show swap-in and swap-out activity, bi and bo show block input and output, and wa and st show I/O-wait and stolen CPU time. Read these fields together and match them to the symptom window.
Linux documents the iowait counter as unreliable, including because its accounting is difficult on multicore systems. Treat a high wa or %iowait reading as a clue. Repeated device latency and queue readings that coincide with application delay are more informative than that CPU percentage alone. Repeated swap activity may point to memory pressure; a high st reading may point to CPU scheduling contention. Neither one identifies the physical cause by itself. For broader CPU and memory checks, see how to check CPU and memory pressure on a VPS.
Interpret the evidence without guessing at the host disk
- Latency, queueing and user impact rise together: the guest's storage path is a reasonable area to investigate. The guest cannot tell you from these numbers alone whether delay is inside its own workload, the virtualisation layer, shared infrastructure or physical storage.
- CPU wait is high but device latency is not: check whether the measurements cover the same interval and whether another bottleneck is present. A single CPU counter is not proof of a disk fault.
- Swap moves repeatedly: compare the readings with available memory and the workload. Memory pressure can add disk activity, but do not resize the VPS until the cause and service boundary are checked.
- CPU steal rises during the slowdown: preserve that separate signal for the responsible operator. Do not relabel CPU scheduling delay as disk latency.
- The guest samples look normal: check application timing, network paths and external dependencies. A short sample outside the incident window cannot rule out an earlier burst.
A VPS normally exposes virtual devices to its guest. Guest statistics are not a direct measurement of a provider's physical drive, storage array or other customers' activity. If you need host-level evidence, ask through the support route for your actual service and provide the UTC time window, symptom, device name and redacted readings.
Check the access boundary for your Novasean service
Run administrative commands only where your service grants the required access. Root access is specified for the customer under the VM Start with Managed OS schedule when an accepted order incorporates that schedule; it should not be assumed for every Novasean service or VPS offer. Follow the responsibilities and escalation route in your own order and service schedule.
When reporting a recurring problem, send the exact UTC interval, service impact, sample output and relevant workload change. Remove passwords, tokens, personal data and application arguments before sharing logs. Avoid a benchmark, package installation, reboot or database change as the first diagnostic step: these may change the workload or remove evidence before the cause is understood.
Common questions
Can the VPS be slow if the disk is not full? Yes. Free capacity and request latency measure different things. Check repeated I/O samples during the slowdown rather than treating df as a performance test.
Does high iowait prove that the disk is broken? No. Linux documents the counter's accounting limits. Correlate it with per-device measurements and the same-period application symptom.
Is 100% %util always a storage limit? No. The iostat manual says this can indicate saturation for serial devices but does not reflect performance limits for devices that handle requests in parallel.
Can I see the physical storage device from my VPS? Usually the guest reports the virtual device it has been given. Ask the operator for any host-side evidence available under your service; do not infer physical-drive health from guest statistics.
Should I run a disk benchmark? Not as a first response on a live workload. A benchmark can add I/O and may write data. First preserve read-only samples; arrange any controlled test with the responsible operator.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.