---
title: "Cómo medir IOPS y latencia de disco con fio en Ubuntu 24.04"
description: "Usa fio en Ubuntu 24.04 para medir IOPS, ancho de banda y latencia del disco con pruebas aleatorias y secuenciales, archivos de trabajo y salida JSON."
category: "Rendimiento y Benchmarking"
language: es
source: https://cubepath.com/es/docs/rendimiento-y-benchmarking/benchmarking-de-es-de-disco-con-fio
updated: 2026-09-25
---

# Cómo medir IOPS y latencia de disco con fio en Ubuntu 24.04

fio (Flexible I/O Tester) es la herramienta de referencia para medir el rendimiento de almacenamiento en Linux. Permite definir con precisión el patrón de acceso (aleatorio o secuencial), el tamaño de bloque, la profundidad de cola y el número de procesos, y devuelve IOPS, ancho de banda y percentiles de latencia. En este tutorial instalarás fio en Ubuntu 24.04, medirás IOPS aleatorias y rendimiento secuencial, evaluarás la latencia de `fsync` que sufren las bases de datos y guardarás las pruebas en un archivo de trabajo reutilizable.

## Requisitos previos

- Un servidor con Ubuntu 24.04 LTS, por ejemplo un VPS de CubePath.
- Un usuario no root con privilegios `sudo`.
- Al menos 5 GB libres en el sistema de archivos que quieras medir.

> Advertencia: todas las pruebas de esta guía escriben en un **archivo** dentro de un sistema de archivos montado. Nunca apuntes una prueba de escritura de fio a un dispositivo de bloque (por ejemplo `/dev/sda` o `/dev/vdb`) que contenga datos: los sobrescribirás.

## Paso 1: Instalar fio

fio está en los repositorios oficiales de Ubuntu:

```bash
sudo apt update
sudo apt install fio
```

Comprueba la versión:

```bash
fio --version
```

```output
fio-3.36
```

Identifica en qué disco y sistema de archivos está el directorio donde harás las pruebas:

```bash
lsblk
df -h ~
```

Crea un directorio de trabajo en ese sistema de archivos:

```bash
mkdir ~/fio-test
```

## Paso 2: Entender los parámetros clave

Todas las pruebas de esta guía combinan los mismos parámetros. Conviene entenderlos antes de lanzar nada:

| Parámetro | Qué controla | Valores habituales |
|---|---|---|
| `--rw` | Patrón de acceso | `randread`, `randwrite`, `randrw`, `read`, `write` |
| `--bs` | Tamaño de bloque por operación | `4k` para IOPS, `1M` para ancho de banda |
| `--iodepth` | Operaciones en vuelo por proceso | `1` para latencia, `32`-`64` para máximo rendimiento |
| `--numjobs` | Procesos en paralelo | `1`-`4` |
| `--ioengine` | Cómo se envían las operaciones | `libaio` (asíncrono), `sync` |
| `--direct=1` | Salta la caché de páginas del kernel | Siempre, salvo que quieras medir la caché |
| `--size` | Tamaño del archivo de prueba | `4G` o más |
| `--runtime` y `--time_based` | Duración fija de la prueba | `60` segundos |

Sin `--direct=1`, las lecturas pueden servirse desde la RAM y obtendrás cifras irreales.

## Paso 3: Medir IOPS de lectura aleatoria

Las lecturas aleatorias de 4 KB son el patrón más exigente para un disco y el que más se parece a una base de datos o a muchos usuarios leyendo archivos pequeños a la vez:

```bash
fio --name=randread --directory=$HOME/fio-test --size=4G \
  --rw=randread --bs=4k --iodepth=64 --numjobs=1 \
  --ioengine=libaio --direct=1 --runtime=60 --time_based --group_reporting
```

La primera vez, fio crea el archivo de 4 GB (`Laying out IO file`), lo que tarda unos segundos. Al terminar verás un bloque como este:

```output
randread: (groupid=0, jobs=1): err= 0: pid=4121: Thu Sep 25 10:12:44 2026
  read: IOPS=48.2k, BW=188MiB/s (197MB/s)(11.0GiB/60001msec)
    slat (usec): min=2, max=412, avg= 4.18, stdev= 2.07
    clat (usec): min=112, max=9870, avg=1322.40, stdev=301.55
     lat (usec): min=118, max=9874, avg=1326.71, stdev=301.60
    clat percentiles (usec):
     |  1.00th=[  783],  5.00th=[  914], 10.00th=[  996], 20.00th=[ 1106],
     | 30.00th=[ 1172], 40.00th=[ 1237], 50.00th=[ 1303], 60.00th=[ 1369],
     | 70.00th=[ 1434], 80.00th=[ 1532], 90.00th=[ 1680], 95.00th=[ 1811],
     | 99.00th=[ 2212], 99.50th=[ 2442], 99.90th=[ 3261], 99.95th=[ 3818],
     | 99.99th=[ 6128]
```

Cómo leerlo:

- **IOPS**: operaciones por segundo. Es la cifra principal en pruebas de 4 KB.
- **BW**: ancho de banda. En bloques pequeños es simplemente IOPS multiplicado por 4 KB.
- **clat**: latencia de finalización de cada operación. `slat` es el tiempo de envío y `lat` la suma de ambos.
- **Percentiles**: `99.00th=[ 2212]` significa que el 99 % de las lecturas tardó 2,2 ms o menos. Los percentiles altos (99,9 % y 99,99 %) muestran los picos que notan las aplicaciones.

Como referencia orientativa, un disco mecánico da del orden de 100-200 IOPS aleatorias, un SSD SATA decenas de miles y un NVMe cientos de miles. En un VPS, el resultado suele estar marcado por los límites de IOPS del plan y no solo por el hardware.

## Paso 4: Medir IOPS de escritura aleatoria y cargas mixtas

La escritura aleatoria usa la misma sintaxis cambiando `--rw`:

```bash
fio --name=randwrite --directory=$HOME/fio-test --size=4G \
  --rw=randwrite --bs=4k --iodepth=64 --numjobs=1 \
  --ioengine=libaio --direct=1 --runtime=60 --time_based --group_reporting
```

La mayoría de aplicaciones reales mezclan lecturas y escrituras. Esta prueba reparte un 70 % de lecturas y un 30 % de escrituras:

```bash
fio --name=randrw --directory=$HOME/fio-test --size=4G \
  --rw=randrw --rwmixread=70 --bs=4k --iodepth=64 --numjobs=1 \
  --ioengine=libaio --direct=1 --runtime=60 --time_based --group_reporting
```

La salida incluye una línea `read:` y otra `write:` con sus propias IOPS y latencias.

## Paso 5: Medir el rendimiento secuencial

Copias de seguridad, vídeo o importaciones masivas trabajan con bloques grandes en orden. Para medir el ancho de banda máximo usa bloques de 1 MB:

```bash
fio --name=seqread --directory=$HOME/fio-test --size=4G \
  --rw=read --bs=1M --iodepth=16 --numjobs=1 \
  --ioengine=libaio --direct=1 --runtime=60 --time_based --group_reporting
```

```output
  read: IOPS=1742, BW=1742MiB/s (1827MB/s)(102GiB/60003msec)
```

En pruebas secuenciales la cifra relevante es `BW`. Para escritura secuencial, cambia `--rw=read` por `--rw=write`.

## Paso 6: Medir la latencia de fsync para bases de datos

Las bases de datos y sistemas como etcd confirman cada transacción con `fsync` o `fdatasync`, y esperan a que el disco confirme que los datos son persistentes. Esa latencia importa más que las IOPS máximas. Esta prueba escribe bloques pequeños y fuerza `fdatasync` tras cada escritura, con un único proceso y sin cola:

```bash
fio --name=fsync-test --directory=$HOME/fio-test --size=256M \
  --rw=write --bs=4k --ioengine=sync --fdatasync=1 --runtime=60 --time_based
```

Busca en la salida la sección de sincronización:

```output
  fsync/fdatasync/sync_file_range:
    sync (usec): min=210, max=8412, avg=402.18, stdev=190.33
    sync percentiles (usec):
     |  1.00th=[  245],  5.00th=[  265], 10.00th=[  277], 20.00th=[  302],
     | 50.00th=[  359], 90.00th=[  562], 95.00th=[  652], 99.00th=[ 1057],
     | 99.90th=[ 2966], 99.95th=[ 3884], 99.99th=[ 7046]
```

Un percentil 99 por debajo de 10 ms es el mínimo que se suele recomendar para etcd. Valores de pocos cientos de microsegundos son típicos de un NVMe local.

## Paso 7: Crear un archivo de trabajo reutilizable

En lugar de repetir parámetros en la línea de órdenes, fio acepta archivos de trabajo en formato INI. La sección `[global]` define los valores comunes y cada sección siguiente es una prueba. `stonewall` hace que cada prueba espere a que termine la anterior, para que no se ejecuten a la vez.

Crea el archivo:

```bash
nano ~/disk-benchmark.fio
```

Añade este contenido:

```ini
[global]
directory=${HOME}/fio-test
size=4G
ioengine=libaio
direct=1
runtime=60
time_based
group_reporting

[rand-read-4k]
rw=randread
bs=4k
iodepth=64
stonewall

[rand-write-4k]
rw=randwrite
bs=4k
iodepth=64
stonewall

[mixed-70-30-4k]
rw=randrw
rwmixread=70
bs=4k
iodepth=64
stonewall

[seq-read-1m]
rw=read
bs=1M
iodepth=16
stonewall

[seq-write-1m]
rw=write
bs=1M
iodepth=16
stonewall
```

fio expande variables de entorno con la sintaxis `${VAR}`, por eso `${HOME}` apunta a tu directorio personal. Ejecuta el conjunto completo, que tarda unos 5 minutos:

```bash
fio ~/disk-benchmark.fio
```

Cada prueba aparece con su nombre en la salida, seguida de su bloque de IOPS, ancho de banda y latencia.

## Paso 8: Guardar los resultados en JSON

Para comparar ejecuciones, por ejemplo antes y después de cambiar de plan o de sistema de archivos, guarda la salida en JSON:

```bash
fio --output-format=json --output=$HOME/fio-$(date +%F).json ~/disk-benchmark.fio
```

Instala `jq` y extrae las IOPS de lectura y el percentil 99 de latencia (en microsegundos) de cada prueba:

```bash
sudo apt install jq
jq -r '.jobs[] | [.jobname, (.read.iops|floor), (.write.iops|floor), ((.read.clat_ns.percentile["99.000000"] // 0)/1000|floor)] | @tsv' ~/fio-$(date +%F).json
```

```output
rand-read-4k	48213	0	2212
rand-write-4k	0	31877	0
mixed-70-30-4k	25110	10762	3032
seq-read-1m	1742	0	9765
seq-write-1m	0	1508	0
```

Las columnas son: nombre de la prueba, IOPS de lectura, IOPS de escritura y percentil 99 de lectura en microsegundos.

## Paso 9: Limpiar los archivos de prueba

fio no borra los archivos que crea. Elimínalos al terminar para recuperar el espacio:

```bash
rm -rf ~/fio-test
```

## Solución de problemas

- **`fio: looks like your file system does not support direct=1/buffered=0`**: el sistema de archivos (por ejemplo `tmpfs`) no admite `O_DIRECT`. Usa un directorio en un disco real.
- **Resultados de lectura imposibles, de varios GB/s en un disco modesto**: falta `--direct=1`, o el archivo de prueba es tan pequeño que cabe en la caché del controlador. Usa un `--size` de varios GB.
- **`No space left on device`**: `--size` supera el espacio libre. Reduce el tamaño o elige otro directorio.
- **Las IOPS se estancan al subir `--iodepth`**: has alcanzado el límite del dispositivo o del plan. Subir la cola a partir de ahí solo aumenta la latencia.

## Conclusión

Ahora puedes medir IOPS aleatorias, ancho de banda secuencial y latencia de `fsync` con fio, y tienes un archivo de trabajo que repite las mismas pruebas y guarda los resultados en JSON. Como siguientes pasos, puedes medir la base de datos completa con `pgbench` o `sysbench oltp`, comparar sistemas de archivos (ext4 frente a XFS) con el mismo archivo de trabajo, o vigilar el disco en producción con `iostat -x 1` del paquete `sysstat`.