4.8. Opciones utilizadas para probar el rendimiento de VDO con fio

--size

La cantidad de datos que fio envía al objetivo por trabajo.

Véase también la opción --numjobs.

100 GiB

--bs

El tamaño del bloque de cada solicitud de lectura y escritura producida por fio.

Red Hat recomienda un tamaño de bloque de 4 KiB para que coincida con los 4 KiB por defecto de VDO.

4k

--numjobs

El número de puestos de trabajo que crea fio para el punto de referencia.

Cada trabajo envía la cantidad de datos especificada por la opción --size. El primer trabajo envía los datos al dispositivo en el desplazamiento especificado por la opción --offset. Los trabajos subsiguientes sobrescriben la misma región del disco a menos que proporcione la opción --offset_increment, que desplaza cada trabajo desde el lugar donde comenzó el trabajo anterior por ese valor.

Para alcanzar el máximo rendimiento en los discos flash (SSD), Red Hat recomienda al menos dos trabajos. Un trabajo suele ser suficiente para saturar el rendimiento de los discos rotativos (HDD).

1 para HDD, 2 para SSD

--thread

Indica a los trabajos de fio que se ejecuten en hilos en lugar de bifurcarse, lo que podría proporcionar un mejor rendimiento al limitar el cambio de contexto.

none

--ioengine

El motor de E/S que fio utiliza para el benchmark.

Las pruebas de Red Hat utilizan el motor asíncrono sin búfer llamado libaio para probar las cargas de trabajo en las que uno o más procesos realizan peticiones aleatorias simultáneas. El motor libaio permite que un solo hilo realice múltiples peticiones de forma asíncrona antes de recuperar cualquier dato. Esto limita el número de cambios de contexto que requeriría un motor síncrono si proporcionara las peticiones de muchos hilos.

libaio

--direct

Esta opción permite que las peticiones enviadas al dispositivo se salten la caché de páginas del kernel.

Debe utilizar el motor libaio con la opción --direct. De lo contrario, el núcleo utiliza la API de sincronización para todas las solicitudes de E/S.

1 (libaio)

--iodepth

El número de buffers de E/S en vuelo en cualquier momento.

Un valor alto suele aumentar el rendimiento, sobre todo en las lecturas o escrituras aleatorias. Los valores altos garantizan que el controlador siempre tenga solicitudes para procesar. Sin embargo, un valor demasiado alto (normalmente superior a 1K) puede provocar una latencia no deseada.

Red Hat recomienda un valor entre 128 y 512. El valor final es un compromiso y depende de cómo tolere su aplicación la latencia.

128 como mínimo

--iodepth_batch_submit

El número de peticiones de E/S a crear cuando la reserva de búferes de profundidad de E/S comienza a vaciarse.

Esta opción limita el cambio de tareas de las operaciones de E/S a la creación de buffers durante la prueba.

16

--iodepth_batch_complete

El número de operaciones de E/S a completar antes de enviar un lote.

Esta opción limita el cambio de tareas de las operaciones de E/S a la creación de buffers durante la prueba.

16

--gtod_reduce

Desactiva las llamadas a la hora del día para calcular la latencia.

Este ajuste reduce el rendimiento si está activado. Habilite la opción a menos que necesite medir la latencia.

1