Si desea precisión, debe usar fio. Requiere leer el manual ( man fio) pero le dará resultados precisos. Tenga en cuenta que para cualquier precisión, debe especificar exactamente lo que desea medir. Algunos ejemplos:
Velocidad de LECTURA secuencial con bloques grandes (debe estar cerca del número que ve en las especificaciones de su unidad):
fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=read --size=500m --io_size=10g --blocksize=1024k --ioengine=libaio --fsync=10000 --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting
Velocidad de ESCRITURA secuencial con bloques grandes (debe estar cerca del número que ve en las especificaciones de su unidad):
fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=write --size=500m --io_size=10g --blocksize=1024k --ioengine=libaio --fsync=10000 --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting
Random 4K read QD1 (este es el número que realmente importa para el rendimiento en el mundo real a menos que esté seguro):
fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randread --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --fsync=1 --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reporting
Mezcla aleatoria 4K de lectura y escritura QD1 con sincronización (este es el peor número de caso que debería esperar de su unidad, generalmente menos del 1% de los números enumerados en la hoja de especificaciones):
fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randrw --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --fsync=1 --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reporting
Aumente el --sizeargumento para aumentar el tamaño del archivo. El uso de archivos más grandes puede reducir los números que obtiene dependiendo de la tecnología de la unidad y el firmware. Los archivos pequeños darán resultados "demasiado buenos" para los medios de rotación porque el cabezal de lectura no necesita moverse tanto. Si su dispositivo está casi vacío, usar un archivo lo suficientemente grande como para casi llenar el disco le dará el peor comportamiento para cada prueba. En el caso de SSD, el tamaño del archivo no importa tanto.
Sin embargo, tenga en cuenta que para algunos medios de almacenamiento, el tamaño del archivo no es tan importante como el total de bytes escritos durante un período de tiempo corto. Por ejemplo, algunos SSD pueden tener un rendimiento significativamente más rápido con bloques previamente borrados o pueden tener un área flash SLC pequeña que se usa como caché de escritura y el rendimiento cambia una vez que el caché SLC está lleno. Como otro ejemplo, los discos duros Seagate SMR tienen un área de caché PMR de aproximadamente 20 GB que tiene un rendimiento bastante alto, pero una vez que se llena, escribir directamente en el área SMR puede reducir el rendimiento al 10% del original. Y la única forma de ver esta degradación del rendimiento es escribir primero más de 20 GB lo más rápido posible. Por supuesto, todo depende de su carga de trabajo: si su acceso de escritura está lleno de retrasos prolongados que permiten que el dispositivo limpie la memoria caché interna, secuencias de prueba más cortas reflejarán mejor su rendimiento en el mundo real. Si necesita hacer muchas IO, debe aumentar ambas--io_sizey --runtimeparámetros. Tenga en cuenta que algunos medios (p. Ej., La mayoría de los dispositivos flash) recibirán un desgaste adicional de tales pruebas. En mi opinión, si algún dispositivo es lo suficientemente pobre como para no manejar este tipo de prueba, no debe usarse para contener datos valiosos en ningún caso.
Además, algunos dispositivos SSD de alta calidad pueden tener algoritmos de nivelación de desgaste aún más inteligentes donde el caché interno SLC tiene suficiente inteligencia para reemplazar los datos que se reescriben durante la prueba si llega al mismo espacio de direcciones (es decir, el archivo de prueba es más pequeño que el caché SLC total). Para tales dispositivos, el tamaño del archivo comienza a importar nuevamente. Si necesita su carga de trabajo real, es mejor probar con tamaños de archivo que realmente verá en la vida real. De lo contrario, sus números pueden parecer demasiado buenos.
Tenga en cuenta que fiocreará el archivo temporal requerido en la primera ejecución. Se rellenará con datos aleatorios para evitar obtener números demasiado buenos de dispositivos que engañan al comprimir los datos antes de escribirlos en el almacenamiento permanente. El archivo temporal se llamará fio-tempfile.daten los ejemplos anteriores y se almacenará en el directorio de trabajo actual. Por lo tanto, primero debe cambiar al directorio que está montado en el dispositivo que desea probar.
Si tiene un buen SSD y desea ver números aún más altos, aumente por --numjobsencima. Eso define la concurrencia para las lecturas y escrituras. Todos los ejemplos anteriores se han numjobsconfigurado para 1que la prueba se trate de lectura y escritura de procesos de subproceso único (posiblemente con una cola establecida con iodepth). Los SSD de gama alta (por ejemplo, Intel Optane) deberían obtener números altos incluso sin aumentar numjobsmucho (por ejemplo, 4deberían ser suficientes para obtener los números de especificaciones más altos), pero algunos SSD "Enterprise" requieren ir a 32- 128para obtener los números de especificaciones debido a la latencia interna de esos los dispositivos son más altos, pero el rendimiento general es una locura.
