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

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

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

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

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

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

Рассмотрите однако, тщательно, файловую систему, на которую Вы помещаете свой mysql tmpdir; это будет влиять на производительность, особенно запросы, которые делают находящийся на диске filesort () s (см., ОБЪЯСНЯЮТ для получения дополнительной информации).

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

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

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

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

Однако, было бы интересно сделать сводку новостей производительности со всеми теми файловыми системами. (У меня есть меньше, чем никакой энтузиазм по поводу MySQL, тем не менее, таким образом, я не собираюсь предпринимать его. Сравнивание Пост-ГРЭС, OTOH, могло бы быть интересным...),

По моему скромному мнению, стоящие отметить FSS, доступный Linux:

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

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

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

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

Смотрите на это: ReserFS4 X Ext4 X Ext3

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

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

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

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

Может также стоить отметить, что можно выполнить 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.