ݺߣ

ݺߣShare a Scribd company logo
Настройка производительности.
Планировщик ввода/вывода


Andrey Markelov
RHCA
Red Hat, Presales Solution Architect
План выступления

    ●   Типы планировщиков ввода/вывода
    ●   Изменение типа планировщика
    ●   Рекомендации




2
Блочные устройства
               ●   Произвольный доступ
               ●   Зачастую кандидат для
                   настройки
                   производительности
               ●   Разный тип доступа к данным
                   – разная стратегия работы с
                   очередью
               ●   Самая медленная операция –
                   позиционирование данных на
                   HDD 1-15 ms
                   ●   Сортировка
                   ●   Объединение

3
Просмотр и изменение типа планировщика




    ●   echo deadline > scheduler
    ●   Elevator= as | cfq | deadline | noop
4
CFQ – полностью справедливая очередь

    ●   Самый “свежий”
    ●   Планировщик “по умолчанию”
    ●   Хорош когда много процессов с разным
        профилем операций ввода/вывода
    ●   Попроцессные очереди
    ●   ionice
    ●   Cgroups контейнер blkio




5
Գپ貹ٴǰ-прогнозирующий

    ●   До CFQ был планировщиком “по умолчанию”
    ●   Вводит управляемую задержку операций
        ●   antic_exmire в ms
    ●   Перемещяет блоки в очереди, объединя
        операции для уменьшения числа премещений
        головки
    ●   Сбор статистики и эвристические алгоритмы
    ●   Хорош на:
        ●   небольших или медленных дисках
        ●   последовательных чтениях, например web-сервер со статическим
            содержимым
        ●   Лучшая интерактивность (например, рабочие станции)
6       ●   В остальных случаях скорее всего будет уступать другим
Deadline – предельный срок

    ●   Не пытается объединить запросы как
        anticipatory
        ●   read_expire и write_expire в ms
        ●   500 ms и 5 s
    ●   Превосходит CFQ на больших
        последовательных операциях
    ●   Выбор tuned для высоконагруженных систем
        ●   СУБД
        ●   Файловые сервера




7
noop

    ●   FIFO-очередь без приоритезации
    ●   Хорош для:
        ●   Виртуальные машины
        ●   SSD-диски
        ●   Приоритезация на контроллере – SAN уровня предприятия




8
Литература

    ●   access.redhat.com
    ●   IBM redbooks
    ●   RH 442 P&T




9
Спасибо!

  Андрей Маркелов
 andrey@redhat.com
twitter.com/amarkelov

More Related Content

Настройка производительности. Планировщик ввода/вывода

  • 2. План выступления ● Типы планировщиков ввода/вывода ● Изменение типа планировщика ● Рекомендации 2
  • 3. Блочные устройства ● Произвольный доступ ● Зачастую кандидат для настройки производительности ● Разный тип доступа к данным – разная стратегия работы с очередью ● Самая медленная операция – позиционирование данных на HDD 1-15 ms ● Сортировка ● Объединение 3
  • 4. Просмотр и изменение типа планировщика ● echo deadline > scheduler ● Elevator= as | cfq | deadline | noop 4
  • 5. CFQ – полностью справедливая очередь ● Самый “свежий” ● Планировщик “по умолчанию” ● Хорош когда много процессов с разным профилем операций ввода/вывода ● Попроцессные очереди ● ionice ● Cgroups контейнер blkio 5
  • 6. Գپ貹ٴǰ-прогнозирующий ● До CFQ был планировщиком “по умолчанию” ● Вводит управляемую задержку операций ● antic_exmire в ms ● Перемещяет блоки в очереди, объединя операции для уменьшения числа премещений головки ● Сбор статистики и эвристические алгоритмы ● Хорош на: ● небольших или медленных дисках ● последовательных чтениях, например web-сервер со статическим содержимым ● Лучшая интерактивность (например, рабочие станции) 6 ● В остальных случаях скорее всего будет уступать другим
  • 7. Deadline – предельный срок ● Не пытается объединить запросы как anticipatory ● read_expire и write_expire в ms ● 500 ms и 5 s ● Превосходит CFQ на больших последовательных операциях ● Выбор tuned для высоконагруженных систем ● СУБД ● Файловые сервера 7
  • 8. noop ● FIFO-очередь без приоритезации ● Хорош для: ● Виртуальные машины ● SSD-диски ● Приоритезация на контроллере – SAN уровня предприятия 8
  • 9. Литература ● access.redhat.com ● IBM redbooks ● RH 442 P&T 9
  • 10. Спасибо! Андрей Маркелов andrey@redhat.com twitter.com/amarkelov