¿Por qué mi NVMe es más lento que mi SSD?

En este artículo, veremos algunos de los matices del subsistema de E / S y su impacto en el rendimiento.



Hace un par de semanas, me encontré con la pregunta de por qué NVMe en un servidor es más lento que SATA en otro. Observé las características de los servidores y me di cuenta de que era una pregunta capciosa: NVMe era del segmento de usuarios y el SSD era del segmento de servidores.



Obviamente, comparar productos de diferentes segmentos en diferentes entornos es incorrecto, pero esta no es una respuesta técnica exhaustiva. Aprendamos los conceptos básicos, experimentemos y respondamos la pregunta.

Que es fsync y donde se usa

Para acelerar el trabajo con las unidades, los datos se almacenan en búfer, es decir, se almacenan en una memoria volátil hasta que se presenta una oportunidad conveniente para guardar el contenido del búfer en la unidad. Los criterios de "oportunidad" están determinados por el sistema operativo y las características de la unidad. En caso de un corte de energía, se perderán todos los datos del búfer.



Hay una serie de tareas en las que debe asegurarse de que los cambios en un archivo se escriban en la unidad y no en un búfer intermedio. Esta confianza se puede obtener mediante la llamada al sistema fsync compatible con POSIX. La llamada fsync inicia una escritura forzada desde el búfer a la unidad.



Demostremos el efecto de los búferes con un ejemplo artificial en forma de programa corto en C.

#include <fcntl.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/types.h>

int main(void) {
    /*   answer.txt  ,    --  */
    int fd = open("answer.txt", O_WRONLY | O_CREAT);
    /*     */
    write(fd, "Answer to the Ultimate Question of Life, The Universe, and Everything: ", 71);
    /*  ,      10  */
    sleep(10);
    /*    */
    write(fd, "42\n", 3); 

    return 0;
}

Los comentarios explican bien la secuencia de acciones en el programa. El texto "la respuesta a la pregunta principal de la vida, el Universo y todo eso" será almacenado en búfer por el sistema operativo, y si reinicia el servidor presionando el botón Restablecer durante los "cálculos", el archivo estará vacío. En nuestro ejemplo, la pérdida de texto no es un problema, por lo que fsync no es necesario. Las bases de datos no comparten este optimismo.



Las bases de datos son programas complejos que trabajan simultáneamente con muchos archivos, por lo que quieren estar seguros de que los datos que escriben se guardarán en la unidad, ya que de ello depende la consistencia de los datos dentro de la base de datos. Las bases de datos están diseñadas para registrar todas las transacciones completadas y estar listas para cortes de energía en cualquier momento. Este comportamiento nos obliga a utilizar fsync en grandes cantidades todo el tiempo.

A qué afecta el uso frecuente de fsync

Con E / S normal, el sistema operativo intenta optimizar su comunicación con los discos, ya que las unidades externas son las más lentas en la jerarquía de memoria. Por lo tanto, el sistema operativo intenta escribir tantos datos como sea posible en una llamada a la unidad.



Demostremos el impacto de usar fsync con un ejemplo específico. Tenemos los siguientes SSD como sujetos de prueba:

• Intel® DC SSD S4500 480 GB, conectado a través de SATA 3.2, 6 Gb / s;
• Samsung 970 EVO Plus 500GB, PCIe 3.0 x4, ~ 31 Gbps.

Las pruebas se realizan en Intel® Xeon® W-2255 con Ubuntu 20.04. Sysbench 1.0.18 se utiliza para probar discos. Se crea una partición en las unidades, formateada como ext4. La preparación para la prueba consiste en crear archivos de 100 GB:

sysbench --test=fileio --file-total-size=100G prepare

Ejecución de pruebas:

#  fsync
sysbench --num-threads=16 --test=fileio --file-test-mode=rndrw --file-fsync-freq=0 run

#  fsync   
sysbench --num-threads=16 --test=fileio --file-test-mode=rndrw --file-fsync-freq=1 run

Los resultados de la prueba se presentan en la tabla.

Es fácil ver que NVMe del segmento de clientes lidera con confianza cuando el sistema operativo decide cómo trabajar con los discos y pierde cuando se usa fsync. Esto plantea dos preguntas:

1. ¿Por qué en la prueba sin fsync la velocidad de lectura supera el ancho de banda físico?
2. ¿Por qué un SSD del lado del servidor es mejor para manejar una gran cantidad de solicitudes fsync?

La respuesta a la primera pregunta es simple: sysbench genera archivos llenos de ceros. Así, la prueba se llevó a cabo sobre 100 gigabytes de ceros. Dado que los datos son muy monótonos y predecibles, entran en juego varias optimizaciones del sistema operativo y aceleran significativamente la ejecución.



Si cuestiona todos los resultados de sysbench, puede usar fio.

#  fsync
fio --name=test1 --blocksize=16k --rw=randrw --iodepth=16 --runtime=60 --rwmixread=60 --fsync=0 --filename=/dev/sdb

#  fsync   
fio --name=test1 --blocksize=16k --rw=randrw --iodepth=16 --runtime=60 --rwmixread=60 --fsync=1 --filename=/dev/sdb

La tendencia de caída del rendimiento de NVMe cuando se usa fsync es claramente visible. Puede continuar con la respuesta a la segunda pregunta.

Optimización o farol

Anteriormente dijimos que los datos se almacenan en un búfer, pero no especificamos cuál, ya que no era importante. No profundizaremos en las complejidades de los sistemas operativos ahora y destacaremos dos tipos generales de búferes:

• programa;
• hardware.

El búfer de software se refiere a los búferes que están en el sistema operativo y el búfer de hardware se refiere a la memoria volátil del controlador de disco. La llamada al sistema fsync envía un comando a la unidad para escribir datos desde su búfer al almacenamiento principal, pero no puede controlar la exactitud de la ejecución del comando.



Dado que los SSD funcionan mejor, se pueden hacer dos suposiciones:

• el disco está diseñado para tal carga;
• el disco fanfarronea e ignora el comando.

Puede ver el comportamiento deshonesto de la unidad si ejecuta una prueba de falla de energía. Puede verificar esto usando el script diskchecker.pl , que fue creado en 2005.



Este script requiere dos máquinas físicas: "servidor" y "cliente". El cliente escribe una pequeña cantidad de datos en el disco bajo prueba, llama a fsync y envía información al servidor sobre lo que se escribió.

#   
./diskchecker.pl -l [port]

#   
./diskchecker.pl -s <server[:port]> create <file> <size_in_MB>

Después de ejecutar el script, es necesario desactivar el "cliente" y no devolver la energía durante varios minutos. Es importante desconectar de la electricidad a la persona que se está probando, y no solo realizar un apagado forzado. Después de un tiempo, el servidor se puede conectar y cargar en el sistema operativo. Después de que se inicie el sistema operativo, debe ejecutar diskchecker.pl nuevamente , pero con el argumento de verificación .

./diskchecker.pl -s <server[:port]> verify <file>

Al final de la verificación, verá el número de errores. Si hay 0, entonces el disco ha pasado la prueba. Para excluir una combinación de circunstancias satisfactorias para el disco, el experimento se puede repetir varias veces.



Nuestro S4500 no mostró errores de pérdida de energía, por lo que se puede argumentar que está listo para cargas con muchas llamadas fsync.

Conclusión

Al elegir discos o configuraciones completas listas para usar, recuerde los detalles de las tareas que deben resolverse. A primera vista, parece obvio que NVMe, es decir, SSD con interfaz PCIe, es más rápido que el "clásico" SSD SATA. Sin embargo, como entendemos hoy, en condiciones específicas y con determinadas tareas, este puede no ser el caso.



¿Cómo se prueban los componentes del servidor cuando se alquilan a un proveedor de IaaS?

Te esperamos en los comentarios.