J'ai essayé de trouver des références sur les performances de différents systèmes de fichiers avec MySQL InnoDB, mais je n'en ai pas trouvé.
La charge de travail de ma base de données est l'OLTP typique d'un site web, environ 90 % de lecture, 10 % d'écriture. IO aléatoire.
Parmi les systèmes de fichiers populaires tels que ext3, ext4, xfs, jfs, Reiserfs, Reiser4, etc., lequel est, selon vous, le meilleur pour MySQL ?
Quelle valeur accordez-vous aux 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, même si j'utilise souvent Ext3. Il n'y a donc pas de réel parti pris pour les systèmes de fichiers, mais je vous le fais savoir...
Si le système de fichiers n'est guère plus qu'un conteneur pour vous, optez pour ce qui vous offre les meilleurs temps d'accès.
Si les données ont une valeur significative, il est préférable d'éviter XFS. Pourquoi ? Parce que s'il n'est pas possible de récupérer une partie d'un fichier journalisé _il mettra les blocs à zéro_ et rendent les données irrécupérables. Cette question est corrigé dans le noyau Linux 2.6.22 .
ReiserFS est un excellent système de fichiers, à condition que il ne se bloque jamais . La récupération du journal fonctionne bien, mais si, pour une raison quelconque, vous perdez vos informations de parition ou si les blocs centraux du système de fichiers sont détruits, vous risquez d'être confronté à un dilemme s'il y a plusieurs partitions ReiserFS sur un disque - car le mécanisme de récupération est essentiellement le suivant analyse l'ensemble du disque, secteur par secteur, à la recherche de 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 endommagée, vous pouvez imaginer le chaos que cela provoquera lorsque le processus de récupération recollera les morceaux des deux autres systèmes...
Ext3 est "lent", c'est-à-dire que "j'ai 32 000 fichiers et il faut du temps pour les trouver tous en cours d'exécution". ls ". Si vous avez des milliers de petites tables temporaires partout, vous aurez un peu de mal. Les versions plus récentes incluent maintenant une option d'indexation qui réduit considérablement la traversée des répertoires, mais cela peut encore être pénible.
Je n'ai jamais utilisé JFS. Je peux seulement dire que toutes les critiques que j'ai lues à son sujet étaient de l'ordre de "solide, mais pas le plus rapide du quartier". Il mérite peut-être d'être étudié.
Assez parlé des inconvénients, voyons les avantages :
XFS :
ReiserFS :
Ext3 :
Comme vous le voyez, chacun a ses propres particularités. La question est de savoir laquelle est la moins excentrique pour vous ?
Il peut également être intéressant 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.
En outre, si vous effectuez 90 % de lectures et 10 % d'écritures, à moins que vous n'ayez besoin de la capacité transactionnelle d'InnoDB, vous pourriez envisager de porter votre système sur MyISAM pour de meilleures performances en lecture.
Les réponses ici sont sérieusement obsolètes et doivent être mises à jour car elles apparaissent dans les résultats de Google.
Pour les environnements de production, XFS. À tout moment. XFS est journalisé et non bloquant. Assurez-vous d'avoir les 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_DIRECTN'utilisez pas EXT3 ou même EXT4. Un jour, BTRFS y parviendra.
EXT3, et peut-être EXT4, verrouille au niveau de l'inode, ce qui n'est pas intelligent !
S - www.mysqlperformanceblog.com - http://dev.mysql.com/doc/internals/en/index.html - Comprendre les aspects internes de MySQL par Sasha Pachev - https://www.facebook.com/note.php?note_id=10150210901610933 - http://oss.sgi.com/projects/xfs/training/ - Quelques kits de balançoire, des essais et des erreurs.
EDIT : Une mise à jour. EXT4 semble se porter plutôt bien en ce milieu d'année 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 la recommandation la plus proche de MySQL sur les systèmes de fichiers est XFS, mais ext3 devrait également convenir, ext4 promet d'être une belle amélioration, mais il n'est pas encore tout à fait stable, bien qu'il devrait l'être avant la fin de l'année.
Si vous utilisez des systèmes de fichiers en cluster, les systèmes CXFS, OCFS2 et GFS devraient tous fonctionner.
Je déconseille fortement tout dérivé de Reiser, et JFS, bien qu'il ait été agréable, a été largement battu par XFS et ext4, qui sont tous deux plus largement déployés.
Il est peu probable que cela fasse une grande différence. Utilisez ce que votre distribution utilise par défaut, à condition que ce soit suffisant.
Consacrez vos efforts à d'autres réglages - prenez suffisamment de mémoire vive, un contrôleur raid qui ne craint pas - et corrigez la mauvaise utilisation de la base de données par l'application (NB : c'est le principal coupable dans la plupart des cas où cela n'a pas déjà été fait).
Réfléchissez cependant au système de fichiers sur lequel vous placez votre tmpdir mysql ; cela affectera les performances, en particulier les requêtes qui effectuent des filesort()s 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 dans ce cas, car il est possible d'éviter complètement les entrées-sorties pour les fichiers de courte durée lorsqu'il y a suffisamment de mémoire vive pour les conserver dans le cache. XFS, par exemple, ne prend pas la peine d'écrire les fichiers qui sont supprimés et fermés avant d'avoir été alloués.
Bien sûr, placer un tmpdir sur un tmpfs est intéressant du point de vue des performances, mais il y a un risque d'épuiser l'espace et de voir échouer des requêtes qui auraient autrement abouti (bien que des fichiers temporaires de disque aient été utilisés).
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
