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

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

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

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

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

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

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

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

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

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

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

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

XFS:

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

ReiserFS:

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

Ext3:

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

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

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

InnoDB Raw Devices

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

Ответы здесь серьезно устарели и требуют обновления, так как это происходит в результатах 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 блокируются на уровне инода, а не умны!

Источники: - 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/ - некоторые качели, проб и ошибок.

РЕДАКТИРОВАТЬ: обновление. EXT4, похоже, неплохо справляется с середины 2013 года! BTRFS все еще не является хорошим вариантом. И RHEL вполне может сделать XFS новой файловой системой по умолчанию. Опять же, не используйте EXT3.

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

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

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

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

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

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

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

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

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

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

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

ИМХО стоит отметить, что FS, доступные для Linux:

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

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

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

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

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

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

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

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

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