Traté de buscar un punto de referencia sobre el rendimiento de varios sistemas de archivos con MySQL InnoDB, pero no pude encontrar ninguno.
La carga de trabajo de mi base de datos es la típica OLTP basada en web, aproximadamente 90% de lectura, 10% de escritura. IO aleatorio.
Entre los sistemas de archivos populares como ext3, ext4, xfs, jfs, Reiserfs, Reiser4, etc., ¿cuál crees que es el mejor para MySQL?
Respuestas:
¿Cuánto valoras los datos?
En serio, cada sistema de archivos tiene sus propias compensaciones. Antes de ir mucho más lejos, soy un gran fanático de XFS y Reiser, aunque a menudo ejecuto Ext3. Por lo tanto, no hay un sesgo real del sistema de archivos en el trabajo aquí, solo para hacerle saber ...
Si el sistema de archivos es poco más que un contenedor para usted, elija lo que le proporcione los mejores tiempos de acceso.
Si los datos tienen algún valor significativo, querrá evitar XFS. ¿Por qué? Porque si no puede recuperar una parte de un archivo que está registrado , pondrá a cero los bloques y hará que los datos no sean recuperables. Este problema se soluciona en Linux Kernel 2.6.22 .
ReiserFS es un excelente sistema de archivos, siempre que nunca se bloquee con fuerza . La recuperación del diario funciona bien, pero si por alguna razón pierde la información de su partición, o los bloques centrales del sistema de archivos se vuelan, puede tener una consulta si hay múltiples particiones ReiserFS en un disco, porque el mecanismo de recuperación básicamente escanea el disco completo, sector por sector, buscando lo que "piensa" es el inicio del sistema de archivos . Si tiene tres particiones con ReiserFS pero solo una está rota, puede imaginar el caos que esto causará a medida que el proceso de recuperación une un desastre de Frankenstein de los otros dos sistemas ...
Ext3 es "lento", en un "Tengo 32,000 archivos y toma tiempo encontrarlos a todos funcionando ls" de alguna manera. Si va a tener miles de pequeñas tablas temporales en todas partes, tendrá un poco de pena. Las versiones más nuevas ahora incluyen una opción de índice que reduce drásticamente el recorrido del directorio, pero aún puede ser doloroso.
Nunca he usado JFS. Solo puedo comentar que cada crítica que he leído ha sido algo así como "sólido, pero no el chico más rápido del bloque". Puede merecer investigación.
Basta de contras, echemos un vistazo a los pros:
XFS:
ReiserFS:
Ext3:
Como puede ver, cada uno tiene sus propias peculiaridades. La pregunta es, ¿cuál es la menos peculiar para ti?
También vale la pena señalar que puede ejecutar InnoDB sin un sistema de archivos y mejorar el rendimiento sin sobrecarga del sistema de archivos. No estoy seguro de recomendarlo, pero lo he usado antes sin problemas.
Dispositivos sin procesar de InnoDB
Además, si está ejecutando lecturas del 90% y escrituras del 10%, a menos que necesite la capacidad transaccional de InnoDB, puede considerar la posibilidad de transferir a MyISAM para un mejor rendimiento de lectura.
Las respuestas aquí están seriamente en desuso, y necesitan actualizarse ya que esto está apareciendo en los resultados de Google.
Para entornos de producción, XFS. Cada vez. XFS se registra y no se bloquea. Asegúrese de tener las siguientes variables para una base de datos MySQL moderna (2011/2012) que usa InnoDB en producción:
innodb_file_per_table = 1
innodb_flush_log_at_trx_commit = 1 # an ACID requirement
sync_binlog = 1 # more ACID
innodb_flush_method = O_DIRECT
No use EXT3 o incluso EXT4. Un día BTRFS llegará allí.
EXT3, y tal vez EXT4, se bloquea en el nivel de inodo, ¡no es inteligente!
Fuentes: - www.mysqlperformanceblog.com - http://dev.mysql.com/doc/internals/en/index.html - Entendiendo los aspectos internos de MySQL por Sasha Pachev - https://www.facebook.com/note.php? note_id = 10150210901610933 - http://oss.sgi.com/projects/xfs/training/ - Algunos kits de swing, prueba y error.
EDITAR: Una actualización. ¡EXT4 parece estar funcionando bastante bien a mediados de 2013! BTRFS todavía no es una buena opción. Y RHEL bien puede hacer de XFS el nuevo sistema de archivos predeterminado. Nuevamente, NO use EXT3.
La versión corta es que la más cercana a una recomendación que he visto hacer MySQL en los sistemas de archivos es XFS, sin embargo, ext3 también debería estar bien, ext4 promete ser una buena mejora, pero aún no es bastante estable, aunque debería ser antes de fin de año.
Si está ejecutando sistemas de archivos en clúster, CXFS, OCFS2 y GFS deberían estar bien.
Advertiría enérgicamente contra cualquier derivado de Reiser y JFS, aunque una vez que agradable ha sido superado principalmente por XFS y ext4, que están más ampliamente implementados.
No es probable que haga mucha diferencia. Vaya con lo que su distribución use como predeterminada, siempre que sea suficiente.
Dedique su esfuerzo a ajustar otras cosas, obtenga suficiente ram, obtenga un controlador de incursión que no apesta y corrija el uso lamentable (ab) de la aplicación de la base de datos (NB: este es el principal culpable en la mayoría de los casos donde aún no lo ha hecho ha hecho).
Sin embargo, considere cuidadosamente el sistema de archivos en el que puso su mysql tmpdir; esto afectará el rendimiento, particularmente las consultas que realizan archivosort () basados en disco (vea EXPLICAR para más detalles).
Creo que un sistema de archivos que admita la asignación retrasada es realmente útil aquí, ya que puede evitar IO por completo para archivos de corta duración cuando hay suficiente memoria RAM para mantenerlos en la memoria caché. XFS, por ejemplo, no se molesta en escribir archivos que se eliminan y cierran antes de que se hayan asignado.
Por supuesto, poner un tmpdir en un tmpfs es atractivo desde una perspectiva de rendimiento, pero conlleva el riesgo de agotar el espacio y tener consultas que de otro modo tendrían éxito (aunque con archivos temporales de disco utilizados) fallarán.
No encuentro ningún artículo reciente con "rodeos" de referencia en MySQL que se ejecutan en varios sistemas de archivos. Dada la carga de trabajo que describe, dudo que la fragmentación a nivel de archivo sea un gran problema. Sin un punto de referencia formal, no puedo decir nada que deba tomar como autoritario, pero mi instinto dice que cada sistema de archivos que mencionó anteriormente tendrá un rendimiento aproximado en el mismo estadio (es decir, todos en el mismo orden de magnitud para los números de rendimiento) .
La base de datos realmente está ejecutando el programa, ya que el sistema de archivos solo administra grandes extensiones a las que accede el motor de almacenamiento.
Aún así, sería interesante hacer un resumen del rendimiento con todos esos sistemas de archivos. (Sin embargo, tengo poco entusiasmo por MySQL, así que no voy a emprenderlo. Benchmarking Postgres, OTOH, podría ser interesante ...)
En mi humilde opinión, vale la pena señalar que los FS disponibles para Linux son:
Se sabe que XFS (velocidad de lectura deficiente) es liviano en los recursos del sistema y rápido con archivos grandes pero deficiente para manejar muchos archivos pequeños.
ReiserFS (velocidad de escritura deficiente) no es muy amable con los recursos del sistema, pero funciona muy bien con muchos archivos pequeños.
EXT3 se encuentra en el medio, con un rendimiento aceptable en todos los campos (la razón por la que se considera el Linux FS predeterminado ).
Todavía no he usado EXT4, no ReiserFS4, pero he examinado algunos puntos de referencia y ReiserFS parece tener el mejor rendimiento en lo que respecta a la velocidad de lectura, que usted dijo que era lo más importante para usted.
Echa un vistazo a esto: ReserFS4 X Ext4 X Ext3
Recomendaría Ext3 por su estabilidad, seguridad y madurez, pero si la velocidad de lectura es lo más importante para usted, debería considerar ReiserFS.
Recuerde que también debe considerar el uso de la CPU, la estabilidad, la seguridad, etc., antes de elegir un FS.
Y, por supuesto, hacer un piloto, probar y realizar evaluaciones comparativas en su entorno particular siempre es la mejor manera de saber qué funcionará mejor para usted.
PD: Hubiera publicado más puntos de referencia, pero no puedo publicar más de un enlace.