Я попытался найти тесты производительности различных файловых систем с MySQL InnoDB, но не нашел.
Моя рабочая нагрузка базы данных - это типичный веб-протокол OLTP, около 90% чтения, 10% записи. Случайный ввод-вывод.
Среди популярных файловых систем, таких как ext3, ext4, xfs, jfs, Reiserfs, Reiser4 и т.д., какая, по вашему мнению, лучше всего подходит для MySQL?
Насколько вы цените данные?
Серьезно, у каждой файловой системы есть свои компромиссы. Прежде чем я пойду дальше, я большой поклонник XFS и Reiser, хотя я часто использую Ext3. Таким образом, здесь нет реальной предвзятости файловой системы, просто даю вам знать ...
Если файловая система для вас - не более чем контейнер, тогда используйте то, что обеспечивает вам лучшее время доступа.
Если данные имеют какое-либо существенное значение, вам следует избегать XFS. Зачем? Потому что, если он не может восстановить часть файла, который ведется он обнулит блоки и сделать данные невозможными для восстановления. Эта проблема исправлено в ядре Linux 2.6.22.
ReiserFS - отличная файловая система при условии, что он никогда не разбивается. Восстановление журнала работает нормально, но если по какой-то причине вы теряете информацию о разделах или основные блоки файловой системы сдуваются, у вас могут возникнуть затруднения, если на диске несколько разделов ReiserFS - потому что механизм восстановления в основном сканирует весь диск, сектор за сектором, в поисках того, что, по его мнению, является началом файловой системы. Если у вас есть три раздела с ReiserFS, но только один сломан, вы можете представить себе хаос, который это вызовет, поскольку процесс восстановления сшивает воедино беспорядок Франкенштейна из двух других систем ...
Ext3 "медленный", из "У меня 32 000 файлов, и требуется время, чтобы найти их все работающими". ls"в некотором роде. Если вы собираетесь иметь тысячи маленьких временных таблиц повсюду, вы немного огорчитесь. Новые версии теперь включают параметр индекса, который значительно сокращает обход каталогов, но все же может быть болезненным.
Я никогда не использовал JFS. Я могу только прокомментировать, что каждый обзор этого, который я когда-либо читал, был чем-то вроде «солидный, но не самый быстрый ребенок в блоке». Возможно, это заслуживает расследования.
Довольно минусов, давайте посмотрим на плюсы:
XFS:
ReiserFS:
Ext3:
Как видите, у каждого свои причуды. Вопрос в том, что для вас наименее необычно?
Также стоит отметить, что вы можете запускать InnoDB без файловой системы и повышать производительность без накладных расходов на файловую систему. Я не уверен, что рекомендовал бы его, но я использовал его раньше без проблем.
Необработанные устройства InnoDB
Кроме того, если вы используете 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, блокируются на уровне 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/ - Какой-то комплект качелей, проб и ошибок.
РЕДАКТИРОВАТЬ: обновление. По состоянию на середину 2013 года EXT4 выглядит неплохо! BTRFS по-прежнему не лучший вариант. И RHEL вполне может сделать XFS новой файловой системой по умолчанию. Опять же, НЕ используйте EXT3.
Краткая версия заключается в том, что наиболее близкой к рекомендации, которую я видел в MySQL для файловых систем, является XFS, однако ext3 также должен быть в порядке, ext4 обещает быть хорошим улучшением, но он все еще не совсем стабилен, хотя он должен быть до конец года.
Если вы используете кластерные файловые системы CXFS, OCFS2 и GFS, все должно быть в порядке.
Я настоятельно рекомендую избегать любых производных от Reiser и JFS, хотя когда-то хороший, в основном проигрывает XFS и ext4, которые широко используются.
Вряд ли это будет иметь большое значение. Используйте то, что ваш дистрибутив использует по умолчанию, если этого достаточно.
Потратьте свои усилия на настройку других вещей - получите достаточно оперативной памяти - получите контроллер рейда, который не отстой - и исправьте неудачное (ab) использование базы данных приложением (NB: это главный виновник в большинстве случаев, когда он еще не сделано).
Однако внимательно рассмотрите файловую систему, в которую вы помещаете mysql tmpdir; это повлияет на производительность, особенно на запросы, которые выполняют сортировку файлов на диске (более подробную информацию см. в EXPLAIN).
Я думаю, что файловая система, поддерживающая отложенное выделение, здесь действительно удобна, так как вы можете полностью избежать ввода-вывода для короткоживущих файлов, когда оперативной памяти достаточно, чтобы хранить их в кеше. XFS, например, вообще не беспокоится о записи файлов, которые удаляются и закрываются до того, как они будут размещены.
Конечно, размещение tmpdir в tmpfs является привлекательным с точки зрения производительности, но приводит к риску исчерпания места и запросов, которые в противном случае завершились бы успешно (хотя и с использованием временных файлов на диске).
Я не нахожу недавних статей с обзорами тестов MySQL, работающих в различных файловых системах. Учитывая описанную вами рабочую нагрузку, я сомневаюсь, что фрагментация на уровне файлов будет серьезной проблемой. Без формального теста я не могу сказать ничего, что вы должны были бы считать авторитетным, но моя интуиция говорит, что каждая файловая система, которую вы упомянули выше, будет работать примерно в одном и том же порядке (то есть все в одном порядке величины для показателей производительности) .
База данных действительно запускает шоу, поскольку файловая система просто управляет большими экстентами, к которым обращается механизм хранения.
Тем не менее, было бы интересно провести обзор производительности всех этих файловых систем. (Однако у меня нет энтузиазма по поводу MySQL, поэтому я не собираюсь браться за это. Тестирование Postgres, OTOH может быть интересно ...)
ИМХО стоит отметить доступные для linux ФС:
XFS (низкая скорость чтения), как известно, мало использует системные ресурсы и работает быстро с большими файлами, но плохо справляется с большим количеством маленьких файлов.
ReiserFS (низкая скорость записи) не очень эффективна для системных ресурсов, но очень хорошо работает с большим количеством небольших файлов.
EXT3 находится посередине, приемлемо работая во всех полях (причина, по которой он считается дефолт Linux FS).
Я еще не использовал EXT4, а не ReiserFS4, но я просмотрел некоторые тесты, и ReiserFS, похоже, имеет лучшую производительность, когда дело доходит до скорости чтения, которая, как вы сказали, была для вас наиболее важной.
Взгляните на это : Резервный FS4 X Ext4 X Ext3
Я бы порекомендовал Ext3 за его стабильность, безопасность и зрелость, но если для вас важнее всего скорость чтения, вам следует подумать о ReiserFS.
Помните, что вы также должны учитывать использование ЦП, стабильность, безопасность и т. Д., Прежде чем выбирать FS.
И, конечно же, создание пилотного проекта, тестирование и тестирование производительности в вашей конкретной среде - это всегда лучший способ определить, что лучше всего подойдет вам.
PS: Я бы опубликовал больше тестов, но я не могу опубликовать более одной ссылки.