innodb_flush_method = O_DIRECT vs O_DSYNC impacto en el rendimiento en ext3 con partición de disco LVM

En uno de mis entornos de producción, tenemos dos instancias ejecutándose en un clúster RedHat, con una instancia de producción asociada al clúster.

Tenemos 125G de memoria principal con 24G InnoDB buffer pool ocupado por instancia1 y 12G ocupado por instancia2, que no está asociado con el clúster RedHat. Los registros de datos y transacciones se encuentran en la partición del disco LVM con un sistema de archivos ext3.

Para un aumento de rendimiento y mejor de E / S de las que he decidido cambiar innodb_flush_methoda O_DIRECT.

Con referencia a la documentación de MySQL:

Cuando los datos InnoDB y los archivos de registro se encuentran en una SAN, se ha encontrado que la fijación innodb_flush_methoda O_DIRECTpuede degradar el rendimiento de simples SELECTdeclaraciones en un factor de tres.

Refiriéndose a MySQL Ver 2 y 3 de alto rendimiento, declaró que los desarrolladores de InnoDB encontraron errores con el uso innodb_flush_method=O_DSYNC. O_SYNCy O_DSYNCson similares a fsync()y fdatasync(): O_SYNCsincroniza datos y metadatos, mientras O_DSYNCque solo sincroniza datos.

Si todo eso parecía una gran explicación sin ningún consejo, este es el consejo:

si usa un sistema operativo similar a Unix y su controlador RAID tiene un caché de escritura respaldado por batería, le recomendamos que lo use O_DIRECT. Si no, ya sea el predeterminado o O_DIRECTprobablemente será la mejor opción, dependiendo de su aplicación.

Al buscar en Google, obtuve este informe de referencia: en O_DSYNCvsO_DIRECT

Informe de marca de banco:
===================
Prueba transaccional compleja de fila 1B, 64 hilos

 * SAN O_DIRECT: solicitudes de lectura / escritura: 31560140 (8766.61 por segundo)
 * SAN O_DSYNC: solicitudes de lectura / escritura: 5179457 (1438.52 por segundo)
 * SAN fdatasync: solicitudes de lectura / escritura: 9445774 (2623.66 por segundo)
 * Disco local O_DIRECT: solicitudes de lectura / escritura: 3258595 (905.06 por segundo)
 * Disco local O_DSYNC: solicitudes de lectura / escritura: 3494632 (970,65 por segundo)
 * Fdatasync de disco local: solicitudes de lectura / escritura: 4223757 (1173.04 por segundo.

Sin embargo, O_DIRECTdeshabilita la memoria caché a nivel del sistema operativo, donde se puede deshabilitar el almacenamiento en caché doble que muestra un mejor rendimiento de E / S.

¿Es bueno ir en O_DIRECTlugar de O_DSYNC? Estas dos opciones son un poco confusas. ¿Qué opción puede mostrar un mejor rendimiento de E / S y una mejora en el rendimiento sin ningún impacto en los datos, lecturas / escrituras, especialmente en la producción? ¿Alguna mejor sugerencia basada en tu experiencia personal?

Pude ver la actualización de Rolando en la publicación :

Todavía hay una ligera confusión en ambos parámetros. Donde pude ver la mayoría de las plantillas de configuración de producción usando O_DIRECT, no he visto ninguna recomendación O_DSYNC.

Sistema

• MySQL 5.1.51-enterprise-gpl-pro-log
• Red Hat Enterprise Linux Server versión 5.5
• DELL DRAC con Raid Controller que tiene una memoria caché de escritura de batería de 512 MB
• Controladores Dell PERC H700 con una unidad de batería de respaldo (BBU).

Información Adicional

mysql> muestra variables como 'innodb_thread_concurrency'; 

+ --------------------------- + ------- +
El | Nombre_variable | Valor |
+ --------------------------- + ------- + 
El | innodb_thread_concurrency | 96 |
+ --------------------------- + ------- + 
1 fila en conjunto (0.00 seg) 

mysql> muestra variables como 'innodb_read_io_threads'; 
Conjunto vacío (0.00 seg) 

mysql> muestra variables como 'innodb_write_io_threads'; 
Conjunto vacío (0.00 seg)

Estamos utilizando el complemento predeterminado, así que publiqué la información del estado de InnoDB:

mysql> SELECCIONAR * DESDE complementos DONDE PLUGIN_NAME ME GUSTA '% innodb%' Y PLUGIN_TYPE ME GUSTA 'STORAGE ENGINE' \ G
*************************** 1. fila ******************** *******
           PLUGIN_NAME: InnoDB
        PLUGIN_VERSION: 1.0
         PLUGIN_STATUS: ACTIVE
           PLUGIN_TYPE: MOTOR DE ALMACENAMIENTO
   PLUGIN_TYPE_VERSION: 50151.0
        PLUGIN_LIBRARY: NULL
PLUGIN_LIBRARY_VERSION: NULL
         PLUGIN_AUTHOR: Innobase OY
    PLUGIN_DESCRIPTION: admite transacciones, bloqueo de nivel de fila y claves externas
        PLUGIN_LICENSE: GPL
1 fila en conjunto (0.00 seg)

El 21 de enero de 2009, Peter Zaitsev declaró lo siguiente en mysqlperformanceblog.com

Como un llamado a la acción: seguramente me gustaría que alguien vea si EXT3 puede repararse a este respecto, ya que es, con mucho, el sistema de archivos más común para Linux. También vale la pena investigar si se puede hacer algo en el lado de MySQL, ¿puede abrir binlog con O_DSYNCflag si en sync_binlog=1lugar de usar fsync ayudará? O puede ser binlog preasignación sería una buena solución.

Hasta el momento, no sé de nadie que haya tocado este tema. O_DSYNCcomo opción predeterminada no es una perspectiva atractiva, pero admite escrituras más rápidas que realmente no se verifican. Es por eso que hay tanta publicidad alrededor O_DIRECT.

Puedo decirle que no tiene instalado el complemento InnoDB. Con el complemento InnoDB, deben existir varias variables.

Debe actualizar InnoDB de una de dos maneras:

• Actualice a MySQL 5.5 (Todas las mejoras del complemento InnoDB son parte de MySQL 5.5)
• Actualice el complemento InnoDB

Una vez que lo haya hecho, puede mejorar InnoDB para

• acceder a más CPU y núcleos
• aumentar los hilos de lectura y escritura de E / S
• escalar la capacidad de E / S (esto es especialmente necesario para diferentes medios de almacenamiento)

Aquí están mis publicaciones anteriores sobre la configuración que puede cambiar para esto:

• Sep 12, 2011: ¿Es posible hacer que MySQL use más de un núcleo?
• Sep 20, 2011: Multi núcleos y rendimiento MySQL
• Apr 26, 2012: ¿El rendimiento de la CPU es relevante para un servidor de base de datos?
• Mar 16, 2012: Uso de múltiples núcleos para consultas MySQL individuales en Debian

Siempre tuve la impresión de que O_DIRECTes mejor para el rendimiento, ya que evita el doble almacenamiento en búfer. Además, siempre que tenga RAID de hardware con caché de escritura respaldada por batería. Por supuesto, también depende de la carga de trabajo, ya sea que LEA o ESCRIBA mucho.

Además, pregunta para los expertos: hacer las llamadas adicionales a fsync()para O_DIRECTprovocar una degradación notable en el rendimiento global, o es insignificante? Todavía tengo que ver los puntos de referencia que muestren esto.

Además, tenga en cuenta que Percona ha habilitado la capacidad de configuración innodb_flush_method=ALL_O_DIRECT, que proporciona E / S directa no solo en los archivos de datos de InnoDB, sino también en los registros de transacciones de InnoDB al mismo tiempo.