Cuando se trata de optimizar el sistema para obtener el máximo rendimiento, puede ser muy fácil cometer errores si aplica imprudentemente las prácticas de otras personas. Una de estas prácticas es especificar nobarrier al montar sistemas de archivos.
Cómo nació esta nota
Trabajo como ingeniero en Mail.Ru Cloud Solutions y principalmente me ocupo de todo tipo de almacenamiento de bloques "alrededor y alrededor" en el que se encuentran las máquinas virtuales de nuestros usuarios, y, en consecuencia, a menudo surgen casos interesantes relacionados con el rendimiento y la estabilidad de las máquinas virtuales que se ejecutan en aplicaciones, y especialmente bases de datos.
Como regla general, en casi la mitad de los casos durante el "informe" vemos lo mismo: un sistema de archivos montado con la opción de nobarrier. Y cuando preguntamos: "¿por qué escribiste esta opción?", Casi siempre recibimos una de las opciones de respuesta "Me dijeron que era más rápido / leí que era más rápido / me prepararon así", después de lo cual tratamos de explicarlo cortés y cuidadosamente. Así que no es necesario. Por qué Porque este es el primer paso seguro en el camino hacia la pérdida de datos.
Pequeña excursión
Sistema de archivos: la estructura es muy compleja y altamente cargada. Para garantizar el máximo rendimiento, el almacenamiento en caché y la grabación paralela se utilizan activamente en el proceso. En consecuencia, parte de los datos van al caché y se descartan siempre que sea posible / necesario o "a pedido". Una barrera es una operación especial para forzar que todas las memorias caché se vacíen en el disco.
Cuando se trata de bases de datos, debemos estar seguros de que la transacción confirmada al cliente (aplicación del cliente) ha sido persistente y no desaparecerá, por un lado, y por otro lado, los DBMS utilizan activamente su propio almacenamiento en caché para lograr el máximo rendimiento, y para garantizar la coherencia, se utiliza el registro en diario: el cambio se escribe en el registro, el registro se "sincroniza" y luego el cambio se escribe en los datos (y cuando se escribe, se almacena en la memoria caché). Cuando el registro está lleno, se realiza una sincronización forzada con todos los datos en la memoria caché y el registro comienza a llenarse nuevamente.
Operación de sincronización
Cuando se ejecuta la sincronización, el sistema operativo no solo vacía la memoria caché de la página, sino que por defecto envía un comando para vaciar todas las memorias caché de disco (y, posiblemente, lo hace repetidamente), el llamado
rubor . El funcionamiento de las memorias intermedias de lavado es "costoso" y lleva una cantidad considerable de tiempo, pero es necesario, ya que en los sistemas de archivos el orden de escritura es importante: si se viola, entonces (por ejemplo) puede resultar que durante un reinicio repentino en el archivo habrá basura en lugar de datos, ya que el dispositivo decidió reordenar el registro. Y cuando flush lava a la fuerza todos los cachés, esto asegura que primero se escriba lo que está antes de flush, y solo luego lo que sucede después, es decir, se crea una "barrera" que divide las entradas en "antes de la barrera" y "después de la barrera" (desde aquí y el nombre "barrera de escritura"), y esto hace posible garantizar que los registros posteriores a la barrera no se aplicarán antes que los registros anteriores a la barrera.
Efecto Nobarrier
La opción nobarrier deshabilita el envío de vaciado forzado mientras se ejecuta el sistema de archivos. Esto lleva al hecho de que los registros se pueden reordenar, y si ocurre una falla, el sistema de archivos (y generalmente los datos en el caso general) pueden ser inconsistentes, recordemos lo que se mencionó en el párrafo anterior sobre el orden de grabación.
¿Por qué se incluye esta opción? Para los SSD de bajo costo, la operación de vaciado es muy costosa; por ejemplo, los SSD de bajo costo (y muchos costosos que se posicionan como "servidores") realizan de 10 a 20 mil operaciones de escritura por segundo sin vaciado, y con el vaciado encendido, caen a 1-2 mil. En tales casos, nobarrier proporciona un aumento significativo del rendimiento, creando los riesgos para la integridad de los datos descritos anteriormente.
Entorno virtual
En el caso de una máquina virtual, si, por ejemplo, estamos hablando de la configuración clásica de máquinas virtuales en un hipervisor Linux, tenemos QEMU, un proceso que en realidad es responsable de emular las E / S para el sistema operativo invitado. Y lo más importante, si utilizamos discos sin respaldo de archivo en una máquina virtual, entonces la caché de dicho disco virtual (¿de repente?) Se encuentra en el espacio del usuario, en el espacio de direcciones del proceso QEMU correspondiente. Y si este proceso falla, por ejemplo, de acuerdo con SEGFAULT / SIGSEGV, entonces todas sus memorias caché morirán con él. Un ejemplo de tal controlador de dispositivo de bloque es el controlador RBD (Ceph).
E incluso si no usa Ceph pero iSCSI / FC, por ejemplo, el nivel de falla no desaparece, simplemente cambia de QEMU al sistema operativo host (hipervisor). El hipervisor se cayó: su caché de página murió (esto es cierto para io = 'hilos' en combinación con caché = 'reescritura' o caché = 'inseguro'). Ups
s / Cloud / computadora alienígena / g
Cuando su máquina virtual se implementa en la nube ... Entonces no sabe cómo está configurado el hipervisor, cómo está configurada QEMU, qué controladores de disco están involucrados, si la caché de página del host funciona, etc., y no puede influir en esto en la gran mayoría de los casos. E incluso si es su nube, donde sabe todo esto y más o menos lo controla, no es en absoluto un hecho que su hipervisor no se "caiga", enterrando todo el caché de datos.
Resumen
El uso de nobarrier en la nube significa que es muy probable que ponga sus datos en riesgo. ¿Está seguro de que desea obtener ganancias de productividad a costa de estos riesgos?