Я много раз в этом блоге трогал тему о влиянии фрагментации на производительность работы системы хранения (см. например раз, два, три). Но как-то все это были слова, а как насчет “покажь логи”? Так как я до недавних пор был “безлошадный”, а все мои знакомые “с оборудованием” все как на подбор были “ленивы и нелюбопытны”, чтобы дать документальный ответ на этот вопрос, то поэтому пришлось отвечать самому.
Тут вот, как вы уже заметили, я, наконец, обзавелся на хозяйстве маленьким нетаппчиком, и, пока мы его в продакшн не ввели, гоняю в хвост и в гриву, в том числе отвечаю на назревшие вопросы. ?? первый – о том, влияет ли фрагментация данных на производительность доступа к ним при рандомном характере доступа.
Выше в постах, на которые я сослался, я уже ответил на этот вопрос и прояснил свою позицию. Вкратце: при рандомном доступе производительность от фрагментации данных не зависит. Так как система хранения обращается к данным рандомно, в произвольном, случайном порядке, то нет никакой особенной разницы в том, будут ли блоки данных лежать упорядоченно, или беспорядочно – их всегда будут читать “беспорядочно”. А рандомность обращения, помноженная на рандомность размещения не дает “рандомность в квадрате”, она остается обычной рандомностью, “в первой степени”.
Надеюсь не нужно дополнительно объяснять, почему для современных многозадачных систем, для баз OLTP, для виртуализованных серверных сред почти 100% доступа к данным является рандомным? Последовательный, “секвентальный” доступ встречается в очень узком сегменте, это бэкапы (а у NetApp, к слову, задача бэкапа, как вы помните, решается другим способом, а не последовательным копированием и передачей данных), это базы с характером доступа DSS, и это, отчасти, логи баз данных. Вот, в общем, и все использование секвентального доступа. Остальное все – более или менее чистый рандом.
Поэтому я взял паттерн доступа VM-сервер (40%-write/60%-read, 45%-sequental/55%-random, 4KB block). Секвентальность в последнем случае берется вследствие работы локального кэша хоста. Паттерны эти определил не я, они довольно широко распространены. Вот его и будем кушать мерять.
Тестировал я с помощью IOmeter, который, несмотря на некоторые его недостатки, знаю и люблю. В качестве load-generator использовались виртуальные машины, работающие с достаточно мощного хоста (IBM 3850 X5), который был подключен к стораджу по NFS. Для OS в VM диск выглядел “физическим” LUN без файловой системы, который делался MBR-разделом и форматировался в NTFS со стандартным размером блока (4KB). Раздел делался размером 40GB, на нем создавался тестовый файл IOmeter (iobw.tst), размером 16GB (для гарантированного “пробоя кэша”). На каждой VM делался 4-процессорный vCPU, и, соответственно, запускались 4 Worker, на каждом из которых пускался тестовый паттерн на созданный диск, в 16 потоков ввода-вывода (Outstanding IOs) на каждый Worker, то есть 64 одновременных потока ввода-вывода на диски (контроллер NetApp). Загрузка хост-сервера тестом не превышала при этом 15% (мощная зверюга этот 3850), загрузка стораджа колебалась, но также не превышала 80%. То есть заведомо мы в “потолки” нигде не упирались.
Для минимизации эффектов “прогрева WAFL” (о котором еще будет пост, это также была одна из тем “исследовательской недели”) я делал длинный ramp-up (10 минут), а затем начинался собственно измеряемый тест, длиной 30 минут. Я брал для оценки значение в steady state, ближе к концу теста, и для оценки параллельно проверяемого эффекта “падения производительности” при прогреве – ближе к его началу.
Однако, перед исследователем, в моем лице, встала проблема: как обеспечить “фрагментацию” файла тестирования? Если создать последовательный, упорядоченный файл просто: запускай IOmeter на пустом диске – вот он и создаст свой iobw.tst, то с фрагментацией “на заказ” сложнее.
Для того, чтобы сделать фрагментированный файл я нашел любопытную утилитку, под названием MyDefragmenter, которая, как ясно из названия – дефрагментатор. Но у нее в комплекте есть также программка MyFragmenter :). Она делает вполне ожидаемую из названия вещь :)
Я взял созданный IOmeter тестовый файл и качественно замесил его с помощью этой утилитки. Я фрагментировал с ее помощью этот файл на 250 тысяч кусочков по 64KB каждый (ну, чтоб не было претензий, что гранаты у нас не той системы;), а потом повторно провел тестирование описанными выше паттернами.
Также я проанализировал ситуацию с фрагментацией не только файла на NTFS, но и в WAFL, а затем измерил эффект от работы reallocate в WAFL.
Хочу отдельно отметить, что в данном случае измеренные “попугаи” не могут рассматриваться по абсолютной величине, я не проводил никакого (необходимого) тюнинга системы, и настройки ее “по уму” и по best practices (это я сделаю позже, ту у меня есть некоторые бюрократические процедуры для этого). Целью теста было сравнить два достигнутых параметра производительности: “А” и”Б”, то есть их соотношение, а не достижение абсолютного рекорда, поэтому реплики с мест “чота как-то иопсев маловата!” мы отметем как неорганизованные ;).
Вот какие результаты я получил:
Continue reading ‘В последний раз о фрагментации файлов и производительности’ »
