Оценка влияния фрагментации в ФС на производительность MySQL

22.03.2008 21:25

Пётр Зайцев провел исследование влияния фрагментации в файловой системе на производительность MySQL, а также оценил насколько интенсивная работа MySQL с большим числом таблиц способствует появлению фрагментации в файлах БД.

Выводы:

Одновременное помещение данных в разные таблицы приводит к фрагментации данных на диске, приводящей к потере производительности при последовательном чтении данных;
На производительность MyISAM фрагментация влияет больше, чем на Innodb;
Метод ступенчатого распределения блоков данных (extent allocation, когда размер файла увеличивается резервируя сразу 64 страницы по 16Кб каждая) помогает Innodb;
Фрагментация влияет на Innodb в меньшей степени, в случае хранения таблиц в отдельных файлах.

исправить +/–

Главная ссылка к новости (http://www.mysqlperformanceblo...)

Лицензия: CC BY 3.0

Короткая ссылка: https://opennet.ru/14896-mysql

Ключевые слова: mysql, benchmark, tune, speed, fs

При перепечатке указание ссылки на opennet.ru обязательно

Обсуждение (8)

1.3, pavlinux (ok), 02:31, 23/03/2008 [ответить] [﹢﹢﹢] [ · · · ] [к модератору]	+/–
Не убедительная, я бы даже сказал, отсутствующая оценка фрагментации файловой системы. То что они, файлы, у него очень медленно читаются это только показывает, что файлы медленно читаются, и как один из вариантов медлительности - фрагментация.

1.7, Lindemidux (??), 10:52, 23/03/2008 [ответить] [﹢﹢﹢] [ · · · ] [↓] [к модератору]	+/–
Я устраивал 100% фрагментацию файловым системам (был забит каждый второй кластер), только проблема в том, что в Linux, что во FreeBSD фрагментация похоже пропадает через 10-20 часов, потому что абсолютно исчезают тормоза, а в венде фиг вам, проводите дефрагментацию, правда после 50 часов ожидания я дождался. Записывал в nix на фрагментированные разделы данные, так эти данные после каждой перезаписи все быстрее и быстрее записывались, а в венде какое-то жуткое падение скорости. После дефрагментации скорость была все равно жутко упавшей.

2.8, pavlinux (ok), 17:58, 23/03/2008 [^] [^^] [^^^] [ответить] [к модератору]	+/–
А вы пробовали после загрузки, find / -noleaf > /dev/null Потом всё так быстро работает... :)

3.10, spamtrap (ok), 10:25, 24/03/2008 [^] [^^] [^^^] [ответить] [к модератору]	+/–
чёт не понял этого шаманства...может кто-то объяснить?

4.11, керос (?), 11:26, 24/03/2008 [^] [^^] [^^^] [ответить] [к модератору]	+/–
кэшируется

5.12, pavlinux (ok), 15:27, 24/03/2008 [^] [^^] [^^^] [ответить] [к модератору]	+/–
>кэшируется Угу :) Особенно на журнулюруюмуюх FS

1.14, Аноним (14), 07:03, 25/03/2008 [ответить] [﹢﹢﹢] [ · · · ] [↑] [к модератору]	+/–
Именно по этой причине СУБД должна хранить свои данные на raw разделе. Да и механизмам кеширования СУБД лучше знать что и когда кешировать и как располагать данные.

1.15, Кокашко (?), 21:15, 10/08/2009 [ответить] [﹢﹢﹢] [ · · · ] [к модератору]	+/–
Пепец О_о

игнорирование участников | лог модерирования

Добавить комментарий

Имя:

E-Mail:

Текст: