Diagnose disk I/O on a Linux VPS with iostat

When a Linux game server becomes slow, the processor is not always to blame. Saturation of input/output operations, often shortened to I/O, can slow down backups, world loads, logs, and service responses. This guide explains how to install the iostat tool, collect the useful indicators, and isolate the cause without confusing a full disk, insufficient memory, and actually saturated storage.

Before measuring disk I/O

Work during or just after the slowdown you observed. A measurement taken only at rest can hide the problem. Note the time, the service concerned, the duration of the lag, and the operations in progress, such as a backup or a map generation. Keep an SSH session open and avoid restarting the server before you have collected the first elements.

A Linux VPS is a virtual machine hosted in a virtualization infrastructure. Its storage may rest on an SSD, its resources may be shared or dedicated depending on the plan, and administration is often done with root access. RAM, CPU, disk space, bandwidth, and the quality of the application all influence the perception of performance. The diagnosis below measures an I/O load on the system, without assuming the exact type of storage your provider uses.

Start by checking the available space and memory. An almost-full partition can prevent a service from writing, while swap can give the impression of a slow disk. These checks do not yet prove I/O saturation, but they avoid a false conclusion.

df -h
free -h
uptime

Install iostat on Ubuntu or Debian

On Ubuntu and Debian, the iostat command is provided by the sysstat package. Install it from the repositories configured on the VPS, then check that the command responds. The command requires administrator rights for the installation, but reading the statistics can then depend on your system's configuration.

sudo apt update
sudo apt install sysstat
iostat --version

For a one-off diagnosis, installing the command is enough. If you then enable historical collection, check your system's policy and the space reserved for logs. Do not modify the configuration of a production server without keeping a copy of the file concerned.

Run a readable measurement

Request an extended display of the devices and a repeated measurement. The first interval can reflect an average since boot, while the following intervals show more recent activity. For example, use two samples spaced five seconds apart.

iostat -xz 5 2

Depending on the sysstat version, the columns can vary slightly. Read the header displayed by your system rather than copying an interpretation from another machine. Keep the output with the time and the context of the test to compare it with a normal period.

Read the main indicators

In the devices section, r/s and w/s indicate the number of read and write operations per second. rkB/s and wkB/s indicate the transferred volumes. These values describe activity, but high activity is not automatically an incident.

await represents the average wait time of an operation, in milliseconds in the usual display. A persistent rise means that requests wait longer. aqu-sz helps observe the average length of the queue. %util indicates the time during which the device handles I/O over the interval. No indicator should be interpreted alone, and there is no universal threshold valid for all storage and all workloads.

Above all, compare the slowdown intervals with a normal period. A queue that rises at the same time as await and a high utilization of the device is a stronger signal than a single throughput peak.

Distinguish storage, processes, and memory

If iostat reports significant activity, look for the process causing it. The available tools vary according to your distribution and your privileges. A backup, a log rotation, a MySQL database, or the loading of a game server can all produce normal I/O. On a VPS that also hosts an Apache website, a CMS, an FTP service, Plesk, or a backup task, the activity can come from a use other than the game. The goal is to identify the correlation with the slowdown, not to kill a process immediately.

ps aux --sort=-%cpu | head
ps aux --sort=-%mem | head
vmstat 5 3

In vmstat, observe memory activity and I/O in parallel. If available RAM is low and the system heavily uses swap, fix the memory pressure first. If swap stays low but the disk queue and await rise during a specific operation, examine that operation and its schedule.

Network services such as DNS, an administration panel, or a connection to an IP address do not prove disk saturation. A firewall can block a flow, a bandwidth limit can slow a download, and a domain name problem can prevent a site from responding. Check these leads separately instead of attributing every symptom to I/O.

Link the measurement to the hosting

A virtual server is not an isolated physical server. In a VPS or cloud offering, virtualization presents one or more devices to the system, but real performance also depends on the storage layer and the load of the host machine. This explains why the same volume of reads can produce a different await depending on the context. The measurement shows what your instance experiences, without providing by itself a diagnosis of the entire infrastructure.

Do not automatically transpose a result obtained on shared hosting, a dedicated server, a private server, or several virtual machines. A panel or a managed service can trigger scheduled tasks that are invisible from your application. Conversely, a VPS intended to host a game does not have the same priorities as a web server, an e-commerce site, databases, or automation scripts. So document the role of each service before comparing a VPS plan, a cloud server, or a dedicated machine.

Act without making the incident worse

Before any action, back up the configuration and confirm the service responsible. Postpone a non-urgent backup, reduce a scheduled task that is too concurrent, or analyze the logs to understand the origin of the writes. Do not delete log files at random and do not run a defragmentation on a VPS without knowing the underlying storage type.

If disk space is almost full, identify the large directories and check the retention policy before any cleanup. If RAM is insufficient, reducing concurrency or upgrading the plan can be more relevant than an iostat change. If the system is healthy but an application writes without limit, fix its configuration and test the change in a controlled window.

If the problem comes back, schedule several short samples during periods of load. Compare the same devices, the same services, and the same times. For a game server, measure separately the startup, a backup, a map change, and a period with connected players. This series lets you document a need for application optimization or resource scaling.

Diagnosis checklist

• Note the time and the symptom on the player or administrator side.
• Check df -h, free -h and uptime.
• Install sysstat and run iostat -xz 5 2.
• Compare several intervals, not just the first line.
• Relate await, aqu-sz, %util and throughput.
• Identify the operation that writes or reads at the moment of the slowdown.
• Keep the outputs before modifying a task or a service.

If the measurements show a lasting load that exceeds what your configuration can absorb, a Linux VPS sized for the server's use can simplify operations. Depending on your project, you can also compare a virtual server with a dedicated server, check the backup options, and choose the environment that matches your needs. Check the plan's details before choosing an upgrade.

To continue your diagnosis, also read the FiveM server performance optimization guide, the zombie processes guide, the Pterodactyl backup method, the first security settings of a dedicated server, and the dedicated servers page.