Вопрос: Какая лучшая файловая система Linux для MySQL (InnoDB)?


Я попытался найти контрольный показатель производительности различных файловых систем с MySQL InnoDB, но не смог найти.

Моя рабочая нагрузка базы данных - это типичный веб-OLTP, около 90% читать, 10% писать. Случайный IO.

Среди популярных файловых систем, таких как ext3, ext4, xfs, jfs, Reiserfs, Reiser4 и т. Д., Какой, по вашему мнению, лучший для MySQL?


47
2018-06-20 19:06


Источник




Ответы:


Сколько вы цените данные?

Серьезно, каждая файловая система имеет свои собственные компромиссы. Прежде чем я пойду намного дальше, я большой поклонник XFS и Райзера, хотя я часто запускаю Ext3. Таким образом, здесь нет реального искажения файловой системы, просто давая вам знать ...

Если файловая система немного больше, чем контейнер для вас, то идите с тем, что предоставляет вам лучшее время доступа.

Если данные имеют какое-либо существенное значение, вы захотите избежать XFS. Зачем? Потому что, если он не может восстановить часть файла, который ведется журналом он будет обнулять блоки и сделать данные невосстановимыми. Эта проблема исправлено в Linux Kernel 2.6.22,

ReiserFS - отличная файловая система, при условии, что он никогда не падает, Восстановление журнала работает отлично, но если по какой-то причине вы потеряете информацию о своем падении, или основные блоки файловой системы сдуваются, у вас может возникнуть quandry, если на диске имеется несколько разделов ReiserFS - поскольку механизм восстановления в основном сканирование всего диска, сектор по секторам, поиск того, что он «думает», является началом файловой системы, Если у вас есть три раздела с ReiserFS, но только один из них взорван, вы можете представить себе хаос, который это вызовет, поскольку процесс восстановления сшит вместе с Frankenstein беспорядком из двух других систем ...

Ext3 «медленный», в «Я имею 32 000 файлов, и для их поиска требуется время ls«Каким-то образом, если вы будете иметь тысячи небольших временных таблиц повсюду, у вас будет небольшая скорбь. Новые версии теперь включают параметр индекса, который резко сокращает обход каталога, но он все равно может быть болезненным.

Я никогда не использовал JFS. Я могу только прокомментировать, что каждый обзор его, который я когда-либо читал, был чем-то вроде «твердого, но не самого быстрого ребенка на блоке». Это может заслуживать расследования.

Хватит минус, давайте посмотрим на плюсы:

XFS:

  • крики с огромными файлами, быстрое время восстановления
  • очень быстрый поиск в каталоге
  • Примитивы для замораживания и размораживания файловой системы для захоронения

ReiserFS:

  • Очень оптимальный доступ к малым файлам
  • Упаковывает несколько небольших файлов в одни и те же блоки, сохраняя пространство файловой системы
  • быстрое восстановление, время восстановления XFS

Ext3:

  • Исправлено и верно, на основе хорошо протестированного кода Ext2
  • Множество инструментов для работы с ним
  • Может быть повторно смонтирован как Ext2 в крайнем случае для восстановления
  • Могут быть оба сжавшийся и расширен (другие файловые системы могут быть расширены)
  • Новые версии могут быть расширены «вживую» (если вы так дерзаете)

Итак, вы видите, у каждого свои собственные причуды. Вопрос в том, что для вас наименее причудливый?


43
2018-06-22 05:54



Проблема с XLS NULLed файлами была исправлена ​​более 3 лет назад. xfs.org/index.php/... - EvilRyry
Хотя верно, что у меня нет времени в мире, чтобы идти в ногу с изменениями в развитии ядра (помимо работы и семьи), также верно, что есть скрипучие старые варианты развертывания, которые нуждаются в обновлении. Тем не менее, я буду чип в +1 для указания, что исправление было сделано. - Avery Payne


Также стоит отметить, что вы можете запустить InnoDB без файловой системы и повысить производительность без накладных расходов файловой системы. Я не уверен, что рекомендую его, но я использовал его без проблем.

Устройства InnoDB Raw

Кроме того, если вы работаете на 90% чтениях и 10% -ной записи, если вам не нужна транзакционная способность InnoDB, вы можете посмотреть на перенос на MyISAM для лучшей производительности чтения.


12
2017-10-06 17:53



-1 для предложения перейти на MyISAM для лучшей производительности чтения. Имеет много других недостатков и недостатков. Вместо этого InnoDB должен быть настроен правильно. +1 для предложения InnoDB-on-raw-device. - gertvdijk
Я придерживаюсь своего заявления, у MyISAM есть свои недостатки, но есть много хорошего. MyISAM по-прежнему остается боссом для чтения рабочих нагрузок. - Xorlev


Ответы здесь серьезно устарели и нуждаются в обновлении, так как это происходит в результатах Google.

Для производственных сред XFS. Каждый раз. XFS регистрируется и не блокируется. Удостоверьтесь, что у вас есть следующие переменные для современной (2011/2012) базы данных MySQL с использованием InnoDB в производстве:

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

Не используйте EXT3 или даже EXT4. Однажды BTRFS будет там.

EXT3 и, возможно, EXT4, блокируются на уровне inode, а не умны!

Источники:  - www.mysqlperformanceblog.com  - http://dev.mysql.com/doc/internals/en/index.html  - Понимание внутренних языков MySQL Сашей Пачевым  - https://www.facebook.com/note.php?note_id=10150210901610933  - http://oss.sgi.com/projects/xfs/training/  - Некоторые комплекты свинг, проб и ошибок.

EDIT: обновление. EXT4, похоже, неплохо справляется с серединой 2013 года! BTRFS по-прежнему не является хорошим вариантом. И RHEL вполне может сделать XFS новой файловой системой по умолчанию. Опять же, НЕ используйте EXT3.


10
2017-12-12 08:56



В соответствии с Тест Вадима Ткаченко, EXT4 обеспечивает пропускную способность 20% по сравнению с XFS, если используется MySQL 5.5 с InnoDB. Вадим предлагает использовать опцию «dioread_nolock» EXT4, где она доступна (хотя он не использовал ее с тестом). - caligari
Почему блокировка на уровне inode плохая? - jpaugh
другие ответы устарели ... сейчас: 5 лет спустя ... - kaiser
Google «inode lock contention» для проблем с блокировкой inode. - stark


Короткий вариант заключается в том, что наиболее близким к рекомендации, которую я видел MySQL в файловых системах, является XFS, однако ext3 тоже должен быть в порядке, ext4 обещает быть хорошим улучшением, но он все еще не совсем стабилен, хотя он должен быть до конец года.

Если вы используете файловые системы кластера CXFS, OCFS2 и GFS должны быть в порядке.

Я настоятельно предостерег от любых производных Reiser и JFS, хотя когда-то хороший был в основном избит XFS и ext4, которые более широко используются.


8
2018-06-21 10:35





Это вряд ли имеет большое значение. Пойдите с тем, что использует ваш дистрибутив, по умолчанию, при условии, что этого достаточно.

Потратьте свои усилия на настройку других вещей - получите достаточное количество бара - получите контроллер рейда, который не сосать, и исправьте использование хронической (ab) базы данных приложения (NB: это главный виновник в большинстве случаев, когда он еще не сделано).

Однако учтите, что файловая система, на которую вы положили mysql tmpdir; это скажется на производительности, особенно на запросах, которые основаны на файлах filesort () s (подробнее см. EXPLAIN).

Я думаю, что файловая система, которая поддерживает отложенное распределение, действительно удобна здесь, так как вы можете полностью избежать ввода-вывода для короткоживущих файлов, когда имеется достаточное количество бара, чтобы хранить их в кеше. Например, XFS не докучает писать файлы, которые будут удалены и закрыты до того, как они будут выделены.

Конечно, ставить tmpdir на tmpfs привлекательно с точки зрения производительности, но приводит к риску исчерпания пространства и запросов, которые в противном случае были бы успешными (хотя и с временными файлами диска) терпеть неудачу.


6
2018-06-21 11:09





Я не нахожу свежие статьи с базовыми «обзорами» в MySQL, запущенными на разных файловых системах. Учитывая описанную рабочую нагрузку, я сомневаюсь, что фрагментация файлового уровня будет большой проблемой. Без формального теста я не могу сказать ничего, что вы должны считать авторитетным, но моя кишка говорит, что каждая файловая система, о которой вы упомянули выше, будет выполнять примерно в одном и том же поле (то есть все в том же порядке, что и показатели производительности) ,

База данных действительно запускает показ, так как файловая система просто управляет большими экстентами, к которым обращается механизм хранения.

Тем не менее, было бы интересно сделать обзор производительности со всеми этими файловыми системами. (У меня меньше энтузиазма по отношению к MySQL, поэтому я не собираюсь этого делать. Бенчмаркинг Postgres, OTOH, может быть интересным ...)


4
2018-06-20 19:26



Ты тоже stackoverflow.com/questions/1021854/... дублировать с некоторыми ссылками, которые могут вас заинтересовать - nik


IMHO стоит отметить FS, доступный для Linux:

XFS (слабая скорость чтения), которая, как известно, светится на системных ресурсах и быстро с большими файлами, но плохо справляется с большим количеством небольших файлов.

ReiserFS (низкая скорость записи) не очень хороша для системных ресурсов, но очень хорошо работает с большим количеством небольших файлов.

EXT3 находится между ними, выполняя приемлемо по всем полям (причина, по которой по умолчанию linux FS).

Я еще не использовал EXT4, а не ReiserFS4, но я просмотрел некоторые тесты, и у ReiserFS есть лучшая производительность, когда речь заходит о скорости чтения, что, по вашему мнению, было для вас самым важным.

Взгляните на это : ReserFS4 X Ext4 X Ext3

Я бы рекомендовал Ext3 для его стабильности, безопасности и зрелости, но если скорость чтения важна для вас, вам следует подумать о ReiserFS.

Помните, что перед выбором FS необходимо также учитывать использование ЦП, стабильность и безопасность.

И, конечно, подготовка пилота, тестирование и бенчмаркинг в вашей конкретной среде - это всегда лучший способ рассказать, что будет лучше всего работать для вас.

PS: Я бы опубликовал больше тестов, но я не могу разместить более одной ссылки.


2
2018-06-21 19:47