Еще о фрагментации

Несколько слов о теме влияния фрагментации данных на скорость доступа к ним, которую я начал в прошлый понедельник заметкой о теоретической модели, показывающей сравнительно малое влияние фрагментации на случайный (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

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

Оставить комментарий

20/0.133

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.