The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

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

22.03.2008 21:25

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

Выводы:

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


  1. Главная ссылка к новости (http://www.mysqlperformanceblo...)
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/14896-mysql
Ключевые слова: mysql, benchmark, tune, speed, fs
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (8) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 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:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру