Главная Storages, Новое Еще о фрагментации
  • Еще о фрагментации

    126_9 Несколько слов о теме влияния фрагментации данных на скорость доступа к ним, которую я начал в прошлый понедельник заметкой о теоретической модели, показывающей сравнительно малое влияние фрагментации на случайный (random) по характеру доступ.

    Однако как обстоят дела с последовательным (sequental) доступом, ведь такой тоже имеет место быть (пример – записи в лог базы данных)? Очевидно, что тут-то и должна проявиться в полный рост проблема фрагментации, и ее влияния на производительность.

    В блогах я нашел описание любопытного эксперимента (по ссылке часть 5, смотрите в тексте ссылки на предыдущие 4 части).

    Автор создавал сильно фрагментированный, кусками по 2MB и 128KB (5000 и 60000 кусков соответственно), файл, общим размером 10GB, и тестировал на нем последовательные чтения и записи. В качестве дискового хранилища использовались как диски самого сервера (на графиках – DAS), так и раздел на SAN-хранилище EMC Symmetrix DMX-2.

    Вот как описывает тестовое оборудование сам автор: The server was a standard DL580 with 4 single-core sockets (2.0GHz Xeon) with 4GB of RAM. The disk array was a DMX2 with 10K rpm 146GB FC drives in a RAID10 config. The test LUN was 96GB in size (with 8GB disk slices from 24 spindles). Two Emulex LP8000 HBAs were load balanced with PowerPath.

    image

    Первый результат был обескураживающим. В случае использования высокопроизводительного SAN-стораджа, результаты для фрагментированного и дефрагментированного файла, и тестирования последовательной записи блоками по 1К,  были практически идентичными. Очевидно, что эффективное кэширование и хороший запас быстродействия DMX “съели” возможное снижение быстродействия из за присутствия фрагментов.

    Далее автор создал аналогичный раздел на дисках серверов (DAS), и протестировал его.

    image

    И тут мы уже видим значительный эффект от фрагментированности файла при последовательном доступе (почти 30% снижение быстродействия).

    Далее автор уменьшил размеры “блоков фрагментации” до 128KB (то есть увеличил количество фрагментов своего 10GB тестового файла), и проверил эффект на последовательном чтении.

    image

    И снова мы видим, что эффект хорошо заметный на DAS, практически отсутствует на высокопроизводительном SAN-массиве.

    Проявляется ли хоть как-то эффект от фрагментации вообще? Автор обнаружил лишь один параметр:

    image

    На файле размером в 10GB, состоящим из 60 тысяч хаотически разбросанных по диску фрагментов заметно выросло время Latency, задержек чтения. Обратите внимание, что для такого же 10GB-файла с 2MB блоками, разбитого на 5000 таких же разбросанных фрагментов, не было даже и такого эффекта.

    И, наконец, автор измерил время ряда операций:

    image

    В заключение этого поста я хотел бы особо обратить внимание читателя вот на что. Целью поста является не отрицание влияния фрагментации на производительность чтения-записи при последовательном доступе. Уверен, в любом случае можно подобрать такое сочетание режима доступа, размеров файла и блоков чтения, что этот эффект будет отчетливо проявлен.
    Однако я хотел бы привлечь внимание читателей к тому факту, что, зачастую, негативный эффект фрагментации на производительность в реальной жизни, в вашем конкретном случае, и на современных производительных системах хранения, зачастую необъективно переоценивается и ей придается значительно больше значения, чем присутствует на самом деле.
    Из приведенных результатов вы видите, например, что даже на последовательном, наиболее страдающем при фрагментации режиме, на высокопроизводительном сторадже влияние фрагментации, в случае конфигурации, тестируемой автором цитированного поста, практически ничтожно.

    romx

    http://blog.aboutnetapp.ru/

Комментарии

  1. Интересно.. А сколько времени занял данный тест..

  2. Не понял почему скорость последовательного чтения измерена в иопсах.

    А вообще очень попахивает подтасовкой.

  3. А в чем вы предпочитаете измерять скорость? В мегабайтах в секунду? Ну умножьте IOPS на размер блока – получите мегабайты в секунду 😉

  4. Ага, а я оказывается невнимательно графики смотрел 🙂 Там оказывается почти везде кроме первого как раз мегабайты в секунду 🙂
    Но только я что-то их всё равно не очень понимаю.
    Romx, вы не могли бы пояснить 3 и 4 график – что конкретно делалал автор теста и почему на графике он решил отобразить такие зависимости.
    И ещё, может вопрос глупый, но я не понимаю что означает “# outstending I/O s”

  5. На третьем графике – результаты процесс последовательного чтения для двух разных фрагментированных файлов: розовая линия – размер фрагмента 128KB, зеленая – 2MB. Синяя – нефрагментированного файла.
    Тестировались файлы, лежащие на разделе большого SAN-стораджа,
    на четвертом – такие же файлы, но лежащие на дисках самого сервера (DAS – Direct-attached Storage)

    # outstanding IOs это количество одновременных операций ввода-вывода.
    Простое приложение типа notepad.exe это порядка 4-8 одновременных потоков ввода-вывода, хорошо нагруженная база данных типа MS SQL или Oracle – 128-256 одновременных потоков ввода-вывода.
    Этот параметр показывает характеристики быстродействия в зависимости от нагрузки.

  6. Romx
    Т.е. в несколько потоков читаются непревные блоки в 128к? А потом фрагментированныые? Или как?
    Вроде из статьи следует просто последовательное чтение.
    У меня в голове слова “последовательное чтение” и “в несколько потоков” плохо совмещаются.

  7. Ну вы совсем оригинал не читали, да? 😉

    Создается стотыщммильонов файликов размером в необходимый блок фрагментации. Потом случайным образом половина удаляется. Потом на том же разделе создается файл для тестирования. Он получается фрагментированным на заданное количество заданых размеров блоков, лежащих непоследовательно.

    Последовательное чтение это “считали блок с номером N, потом считали блок с номером N+1, потом N+2” и так далее. И таких потоков выода-вывода – 256, у каждого N – разное, но в пределах этого потока чтение – последовательное.

  8. Оригинал от Linchi Shea? нет, не читал.

    А N выбирается произнвольно, так?
    При малом количестве дисков и больших файлах это не сильно отличается от рандом аксес.
    Как правило “тест – последовательное чтение” это синтетический тест с чтением всётаки в один поток.

    Плюч четкой методики тестирования тут нет. если нагрузка создавалась так “с интервалом в секунду запускается новоый поток с начала читающий 10гб файл” то результаты предсказуемы – там всё чтение получается из кеша 🙂

    Сечас перечитал – на сан 24 диска, рейд 10, значит /2.
    А на серевере сколько дисков?