Главная Storages, Virtualization, Новое Имеет ли смысл дефрагментация диска в гостевой ОС?
  • Имеет ли смысл дефрагментация диска в гостевой ОС?

    Тема дефрагментации файловой системы периодически всплывает то на форуме, то просто в почте.

    Так нужна ли дефрагментация в виртуальном мире, которая как известно, сильно помогает в мире физическом?

    Начем с того, что такое фрагментация вообще и каково ее влияние на производительность. Итак, фрагментация — ситуация, когда блоки большого файла разбросаны по физическому диску в случайном порядке. Влияние фрагментации отлично видно на обычной домашней машине с одним жестким диском и большим количеством больших файлов (кино, фото и т.д.). В этом случае для чтения файла (например при копировании) головка диска не может осуществлять линейное последовательное чтение на максимальной скорости, а вынуждена метаться между блоками. Разумеется, все то время, что головка перемещается к нужному цилиндру и ждет начала блока с данными, чтения не происходит. Итог — снижение скорости чтения. Иногда кардинальное снижение, если файл оказался разбит на множество блоков малого размера.
    Лечение — путем последовательных чтения/записи переместить по диску блоки файла таким образом, чтобы в максимальной степени сделать их последовательными и соотв. свести перемещания головки к минимуму.

    Просто, очевидно и ведет к легко измеримому преимуществу. Но так ли это в виртуальном мире?

    А вот здесь как раз зарыт бегемот.

    Давайте представим себе среднего размера инфраструктуру с парой сотен виртуальных машин. Есть производительный массив с множеством дисков в RAID, машины генерируют нагрузку, жизнь движется.
    Влияет ли как-то фрагментация файловых систем внутри ВМ на общую производительность. Парадокс, но практически нет.

    1) Поскольку у нас есть массив из множества дисков, по которым равномерно размазаны данные, значительно снижается влияние перемещения головок — идет практически параллельное чтение с нескольких дисков, причем практически непредсказуемо.
    2) Чем более интеллектуален дисковый массив, тем меньше само влияние самой медленной части дискового массива — дисков. Большой оперативный кэш, кэш второго уровня на флэш-дисках, многоуровненое хранение снижают влияние дисков вплоть до того, что до физических медленных магнитных дисков доходит иногда всего 10% операций чтения. Мощные процессоры, алгоритмы оптимизации и большой зеркалированный кэш с батарейкой позволяют не спешить записывать на диски поток команд как он идет, а делать это оптимальным образом в зависимости от уровня и прочих параметров RAID, в минимальное количество операций.
    3) Одновременная нагрузка с десятков и даже сотен виртуальных машин привод к тому, что только внутри ВМ дисковые операции выглядят как линейное чтение. До дискового массива чтение/запись доходит уже как практически случайная последовательность команд. От того, что файл внутри из одной ВМ расположен непоследовательно, практически ничего не меняется.

    Итого: если ВМ расположены на малоинтеллектуальном массиве начального уровня (или просто на внутреннем RAID сервера) на малом количестве физ. дисков (шпинделей), и их мало, то дефрагментация может иметь смысл и снизить нагрузку на дисковую систему / повысить общую производительность.
    Однако с ростом размеров инфраструктуры и повышении класса дисковой системы фрагментация перестает играть сколько нибудь значимую роль. Зато дефрагментация становится не спасением, а самым настоящим злом. Вспомним, что собой представяет процесс дефрагментации — множество операций чтения / записи (1 к 1) в объеме, доходящим до 100% данных на диске.

    1) Существует такое понятие, как RAID penalty — штраф к производительности в силу того, что используется RAID. Кратко, при использовании RAID 1 (1+0) каждая операция записи со стороны ВМ превращается в 2, когда доходит до дисков. Для RAID 5 — 4, RAID 6 — в 6! Итого, сам процесс дефрагментации очень сильно просаживает производительность. В случае же с флэш-дисками, еще и сильно сокращает срок службы.
    2) Снапшоты. Вы же их используете? Дефрагментация вырастит снапшот до размеров базового диска легко и непринужденно. А кстати, вы не забыли, что снапшот сам по себе дает очень большой штраф к производительности дисковой системы? Который надо умножить на RAID penalty. А потом этот немеряно выросший как на стероидах снапшот надо коммитить. Что снова дает нам много-много записи, которую так не любит RAID.
    3) Вы говорите не используете снапшоты? А как же VMware-level резервное копирование ВМ? Оно реализовано через снапшоты, и существуют совсем ненулевые шансы того, что встретятся вместе задания бэкапа и дефрагментации.
    4) И кстати, вы используете для бэкапа Changed Block Tracking? забудьте о нем, дефрагментация вырастит статистику измененных блоков (хранится в ctk файле) вплоть до объема диска, и вместо быстрого инкрементального бэкапа вы получите медленный полный.
    5) Тонкие диски (thin provisioning). Скажите им тоже «до свидания», при дефрагментации тонкие диски начнут очень быстро превращаться в обычные толстые, и все их преимущества будут сведены на нет.

    А казалось бы, как хорошо все начиналось...

    Не все йогурты одинаково полезны.

    Антон Жбанков

    http://blog.vadmin.ru

Комментарии

  1. RAID penalty — штраф к производительности в силу того, что используется RAID.

    🙂 Штраф по сравнению с чем?

    RAID работает несколько не так. Во всех случаях операции чтения/записи в RAID будут намного более быстрыми чем с единичным диском. Контроллер, организующий RAID отнюдь не тупой и знает как оптимально использовать несколько шпинделей. У контроллера есть кеш, и если контроллер нормальный (с батарейкой) то операция записи произойдет практически мгновенно т.к. данные просто попадут в кеш. Запись на диски также производится совсем не по одному блоку, даже в самых дешевых моделях контроллеров данные пишутся на диски страйпами в оптимальный момент времени... и т.д.

  2. Предлагаем взлом сотовых, анкет, почты и т.д.

    Услуги:

    взлом анкет соц сетей

    детализация сотовых с текстами СМС

    взлом электронной почты

    взлом ICQ

    взлом скайпа

    — многое другое, обращайтесь на olomow@gmail.com

Опубликовать

Я не робот.