none
Дефрагментация raid-массива RRS feed

  • Вопрос

  • Добрый день!

    Подскажите, стоит ли включать в планировщике задач дефрагментацию, если дисковая система состоит из raid-массивов на отдельном контроллере? Для одиночных дисков нужно включать, для ssd вообще отключать, а вот для массивов?

    18 апреля 2013 г. 4:29

Ответы

  • Спасибо, а есть какие-то рекомендации по поводу размера stripe-блока массива? Я всегда выбирал по-умолчанию. Сказывается ли это на  базах данных sql?

    Рекомендации обычно есть у производителя контроллера. Но в реалиях этот параметр мне всегда приходилось подбирать вручную. Т.е., устанавливаешь некоторый размер, создаёшь массив, кладёшь на него данные в нужном виде (это же не всегда бывают файлы ОС), после чего нагружаешь всевозможными нагрузками. При том, под разными типами нагрузок возможны разные значения оптимума.

    Например, я гонял Sybase ASE 15.5 на блоках с размером от 16Кб до 512Кб. При маленьком блоке операции вставки в таблицы БД работали на 15..20% быстрее, чем при большом. При большом же размере почти в два раза сокращалось время на сервисные операции: создание/расширение БД, операциии dbcc и т.п. Опять же, есть возможности и подкручивать параметры БД - размеры страниц, стратегии кеширования т .д.


    Сергей Панченко

    • Помечено в качестве ответа Serg20 18 апреля 2013 г. 6:31
    18 апреля 2013 г. 6:08
    Отвечающий
  • На мой взгляд, не стОит. Если, конечно, речь идёт о дефрагментации средствами Windows Server.

    Во-первых, файловая система NTFS достаточно нетребовательна к фрагментированию. Она by design такая.

    Во-вторых, аппаратный RAID-массив располагает блоки данных по своему усмотрению и алгоритмы его работы скрыты от операционной системы. Гораздо большее значение в плане производительности имеет выбор размера stripe-блока массива.

    Так что, проведение дефрагментации томов на RAID-массиве может иметь только одно практическое значение: нагрузочное тестирование контроллера и тестрирование поверхности дисков. ;-)


    Сергей Панченко

    • Помечено в качестве ответа Serg20 18 апреля 2013 г. 5:50
    18 апреля 2013 г. 5:46
    Отвечающий

Все ответы

  • На мой взгляд, не стОит. Если, конечно, речь идёт о дефрагментации средствами Windows Server.

    Во-первых, файловая система NTFS достаточно нетребовательна к фрагментированию. Она by design такая.

    Во-вторых, аппаратный RAID-массив располагает блоки данных по своему усмотрению и алгоритмы его работы скрыты от операционной системы. Гораздо большее значение в плане производительности имеет выбор размера stripe-блока массива.

    Так что, проведение дефрагментации томов на RAID-массиве может иметь только одно практическое значение: нагрузочное тестирование контроллера и тестрирование поверхности дисков. ;-)


    Сергей Панченко

    • Помечено в качестве ответа Serg20 18 апреля 2013 г. 5:50
    18 апреля 2013 г. 5:46
    Отвечающий
  • Спасибо, а есть какие-то рекомендации по поводу размера stripe-блока массива? Я всегда выбирал по-умолчанию. Сказывается ли это на  базах данных sql?
    18 апреля 2013 г. 5:52
  • Спасибо, а есть какие-то рекомендации по поводу размера stripe-блока массива? Я всегда выбирал по-умолчанию. Сказывается ли это на  базах данных sql?

    Рекомендации обычно есть у производителя контроллера. Но в реалиях этот параметр мне всегда приходилось подбирать вручную. Т.е., устанавливаешь некоторый размер, создаёшь массив, кладёшь на него данные в нужном виде (это же не всегда бывают файлы ОС), после чего нагружаешь всевозможными нагрузками. При том, под разными типами нагрузок возможны разные значения оптимума.

    Например, я гонял Sybase ASE 15.5 на блоках с размером от 16Кб до 512Кб. При маленьком блоке операции вставки в таблицы БД работали на 15..20% быстрее, чем при большом. При большом же размере почти в два раза сокращалось время на сервисные операции: создание/расширение БД, операциии dbcc и т.п. Опять же, есть возможности и подкручивать параметры БД - размеры страниц, стратегии кеширования т .д.


    Сергей Панченко

    • Помечено в качестве ответа Serg20 18 апреля 2013 г. 6:31
    18 апреля 2013 г. 6:08
    Отвечающий