Quel est le meilleur système de fichiers Linux pour MySQL (InnoDB)?
J'ai essayé de rechercher des références sur les performances de divers systèmes de fichiers avec MySQL InnoDB mais je n'en ai pas trouvé.
Ma charge de travail de base de données est l'OLTP Web typique, environ 90% en lecture, 10% en écriture. IO aléatoire.
Parmi les systèmes de fichiers populaires tels que ext3, ext4, xfs, jfs, Reiserfs, Reiser4, etc., lequel pensez-vous est le meilleur pour MySQL?
Combien appréciez-vous les données?
Sérieusement, chaque système de fichiers a ses propres compromis. Avant d'aller plus loin, je suis un grand fan de XFS et de Reiser, bien que j'exécute souvent Ext3. Il n'y a donc pas de véritable biais de système de fichiers à l'œuvre ici, juste pour vous faire savoir ...
Si le système de fichiers est un peu plus qu'un conteneur pour vous, alors optez pour tout ce qui vous offre les meilleurs temps d'accès.
Si les données ont une valeur significative, vous voudrez éviter XFS. Pourquoi? Parce que s'il ne peut pas récupérer une partie d'un fichier qui est journalisé il mettra à zéro les blocs et rendra les données non récupérable. Ce problème est corrigé dans le noyau Linux 2.6.22 .
ReiserFS est un excellent système de fichiers, à condition que il ne plante jamais dur . La récupération du journal fonctionne bien, mais si pour une raison quelconque vous perdez vos informations de partition, ou si les blocs principaux du système de fichiers sont emportés, vous pouvez avoir un dilemme s'il y a plusieurs partitions ReiserFS sur un disque - parce que le mécanisme de récupération est fondamentalement scanne l'intégralité du disque, secteur par secteur, en recherchant ce qu'il "pense" être le début du système de fichiers . Si vous avez trois partitions avec ReiserFS mais qu'une seule est explosée, vous pouvez imaginer le chaos que cela provoquera alors que le processus de récupération assemble un gâchis de Frankenstein des deux autres systèmes ...
Ext3 est "lent", dans un "J'ai 32 000 fichiers et il faut du temps pour les trouver tous fonctionnant en quelque sorte ls". Si vous allez avoir des milliers de petites tables temporaires partout, vous aurez un peu de chagrin. Les versions plus récentes incluent désormais une option d'index qui réduit considérablement la traversée du répertoire, mais cela peut toujours être douloureux.
Je n'ai jamais utilisé JFS. Je peux seulement dire que chaque critique que j'ai lue a été quelque chose du genre "solide, mais pas le gamin le plus rapide du quartier". Cela peut mériter une enquête.
Assez des inconvénients, regardons les avantages:
XFS:
- hurle avec d'énormes fichiers, temps de récupération rapide
- recherche de répertoire très rapide
- Primitives pour geler et dégeler le système de fichiers pour le dumping
ReiserFS:
- Accès hautement optimal aux petits fichiers
- Emballe plusieurs petits fichiers dans les mêmes blocs, conservant ainsi l'espace du système de fichiers
- récupération rapide, rivalise avec les temps de récupération XFS
Ext3:
- Testé et vrai, basé sur un code Ext2 bien testé
- Beaucoup d'outils pour travailler avec
- Peut être remonté en tant qu'Ext2 dans un pincement pour la récupération
- Peut être à la fois réduit et développé (les autres systèmes de fichiers ne peuvent être développés)
- Les dernières versions peuvent être développées "en direct" (si vous êtes si audacieux)
Donc vous voyez, chacun a ses propres bizarreries. La question est, quelle est la moins originale pour vous?
Il convient également de noter que vous pouvez exécuter InnoDB sans système de fichiers et améliorer les performances sans surcharge du système de fichiers. Je ne suis pas sûr de le recommander, mais je l'ai déjà utilisé sans problème.
De plus, si vous exécutez 90% de lectures et 10% d'écritures, à moins que vous n'ayez besoin de la capacité transactionnelle d'InnoDB, vous pourriez envisager de porter sur MyISAM pour de meilleures performances de lecture.
Les réponses ici sont obsolètes et doivent être mises à jour car cela apparaît dans les résultats de Google.
Pour les environnements de production, XFS. À chaque fois. XFS est journalisé et non bloquant. Assurez-vous que vous disposez des variables suivantes pour une base de données MySQL moderne (2011/2012) utilisant InnoDB en production:
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
N'utilisez pas EXT3 ni même EXT4. Un jour, BTRFS y arrivera.
EXT3, et peut-être EXT4, se verrouille au niveau de l'inode, pas intelligent!
Sources: - www.mysqlperformanceblog.com - http://dev.mysql.com/doc/internals/en/index.html - Comprendre les internes MySQL par Sasha Pachev - https://www.facebook.com/note.php?note_id=101502109016109 - http://oss.sgi.com/projects/xfs/training/ - Quelques kits de swing, essais et erreurs.
EDIT: Une mise à jour. EXT4 semble se porter plutôt bien à la mi-2013! BTRFS n'est toujours pas une bonne option. Et RHEL pourrait bien faire de XFS le nouveau système de fichiers par défaut. Encore une fois, n'utilisez PAS EXT3.
La version courte est que le plus proche d'une recommandation que j'ai vu MySQL faire sur les systèmes de fichiers est XFS, mais ext3 devrait également être correct, ext4 promet d'être une belle amélioration, mais il n'est toujours pas assez stable, bien qu'il devrait être avant le la fin de l'année.
Si vous exécutez des systèmes de fichiers de cluster CXFS, OCFS2 et GFS devraient tous être ok.
Je déconseille fortement tout dérivé de Reiser et JFS, bien qu'une fois Nice ait été principalement battu par XFS et ext4 qui sont tous deux plus largement déployés.
Cela ne fera probablement pas beaucoup de différence. Choisissez ce que votre distribution utilise par défaut, à condition que cela soit suffisant.
Passez vos efforts à régler d'autres choses - obtenez suffisamment de RAM - obtenez un contrôleur de raid qui ne craint pas - et corrigez l'utilisation boiteuse (ab) de l'application de la base de données (NB: c'est le principal coupable dans la plupart des cas où il ne l'a pas déjà fait) été fait).
Considérez cependant attentivement le système de fichiers sur lequel vous mettez votre tmpdir mysql; cela affectera les performances, en particulier les requêtes qui effectuent des triages de fichiers sur disque (voir EXPLAIN pour plus de détails).
Je pense qu'un système de fichiers qui prend en charge l'allocation différée est vraiment pratique ici, car vous pouvez éviter IO complètement pour les fichiers de courte durée lorsqu'il y a suffisamment de RAM pour les garder dans le cache. XFS, par exemple, ne dérange pas du tout d'écrire des fichiers qui sont supprimés et fermés avant qu'ils ne soient alloués.
Bien sûr, placer un tmpdir sur un tmpfs est attrayant du point de vue des performances, mais entraîne un risque d'épuisement de l'espace et d'échec des requêtes qui réussiraient autrement (bien qu'avec des fichiers temporaires de disque utilisés).
Je ne trouve aucun article récent avec des "rafles" de référence sur MySQL fonctionnant sur divers systèmes de fichiers. Compte tenu de la charge de travail que vous décrivez, je doute que la fragmentation au niveau des fichiers soit un problème majeur. Sans référence officielle, je ne peux rien dire que vous devriez considérer comme faisant autorité, mais mon instinct dit que chaque système de fichiers que vous avez mentionné ci-dessus va fonctionner à peu près dans le même stade approximatif (c'est-à-dire tous dans le même ordre de grandeur pour les performances) .
La base de données exécute vraiment le spectacle, car le système de fichiers gère simplement de grandes étendues auxquelles le moteur de stockage accède.
Pourtant, il serait intéressant de faire un tour d'horizon des performances avec tous ces systèmes de fichiers. (Cependant, je n'ai aucun enthousiasme pour MySQL, donc je ne vais pas m'y mettre. Benchmarking Postgres, OTOH, pourrait être intéressant ...)
À mon humble avis, les FS disponibles pour Linux sont les suivants:
XFS (mauvaise vitesse de lecture) connu pour être léger sur les ressources du système et rapide avec des fichiers volumineux mais médiocre pour gérer de nombreux petits fichiers.
ReiserFS (faible vitesse d'écriture) n'est pas très gentil avec les ressources système mais fonctionne très bien avec beaucoup de petits fichiers.
EXT3 se situe entre les deux, fonctionnant de manière acceptable sur tous les domaines (la raison pour laquelle il est considéré comme le défaut linux FS).
Je n'ai pas encore utilisé EXT4 pas ReiserFS4 moi-même mais j'ai regardé autour de certains repères et ReiserFS semble avoir les meilleures performances en termes de vitesse de lecture, ce qui, selon vous, était le plus important pour vous.
Jetez un œil à ceci: ReserFS4 X Ext4 X Ext
Je recommanderais Ext3 pour sa stabilité, sa sécurité et sa maturité, mais si la vitesse de lecture est ce qui est le plus important pour vous, vous devriez envisager ReiserFS.
N'oubliez pas que vous devez également considérer l'utilisation du CPU, la stabilité, la sécurité, etc. avant de choisir un FS.
Et bien sûr, faire un pilote, tester et comparer sur votre environnement particulier est toujours la meilleure façon de dire ce qui fonctionnera le mieux pour vous.
PS: j'aurais posté plus de benchmarks mais je ne peux pas poster plus d'un lien.