Управление памятью
контейнеров в проекте OpenVZ
Управление памятью
контейнеров в проекте OpenVZ
Владимир Давыдов
ПланПлан
• Введение
• Исторический экскурс
• Новая концепция управления ресурсами
2
ВведениеВведение
• Контейнеры потребляют ресурсы ОС
• Необходим учёт и контроль
3
1-е поколение: User Beancounters1-е поколение: User Beancounters
• Изначально разрабатывались для upstream Linux, добавлены в Virtuozzo на заре
проекта
• Процессы объединяются в группы, группа = контейнер
• 22 ресурса (количество процессов, открытые файлы, 5 “типов” памяти, ...)
• Жесткие ограничения на потребление
• Нет явного контроля физической памяти
4
2-е поколение: SLM2-е поколение: SLM
• Разработан для Virtuozzo 3.0 (полностью закрытая разработка)
• Попытка отказаться от большого количества параметров
– один основной параметр slmmemorylimit
– SLM демон жонглирует ограничениями и пытается держать
процессы в рамках
– множество вспомогательных параметров для тонкой настройки
• Также нет контроля за физической памятью
5
3-е поколение: VSwap3-е поколение: VSwap
• OpenVZ 2.6.32, Virtuozzo 4.7, PCS 6
• “Вырос” из memory cgroup для upstream Linux
• Основной и единственный ресурс – физическая память
– Первое решение, управляющее и физической памятью тоже
• За несколько лет версия upstream и наша очень сильно разошлись в деталях
– Swap & OOM killer
– Использование свободной памяти хоста
– Балансировка памяти между контейнерами
6
4-е поколение: VCMMD4-е поколение: VCMMD
• Попытка перестать бесконечно изменять upstream контроллер, но
сохранить возможность настраивать поведение ядра для наших
клиентов
• VCMMD = memory cgroup (upstream kernel) + vcmmd (openvz
userspace)
– минимум изменений в ядре Linux
– бОльшая часть логики – в пространстве пользователя
• Один обязательный тип ресурса – физическая память, доступная
контейнеру
7
Управление памятью контейнеров: требуемые эффектыУправление памятью контейнеров: требуемые эффекты
• Контейнеры должны “чувствовать” себя как хост с аналогичным
количеством памяти
• Свободная память хоста (при наличии) должна использоваться для
временного хранения выкинутой из контейнеров памяти
• Долго неиспользуемая память контейнера должна со временем
освобождаться
• Короткие всплески в потреблении памяти должны удовлетворяться
• Возможность задать “гарантии” предоставления памяти
8
1-е приближение: Жесткое разграничение1-е приближение: Жесткое разграничение
●
У каждого контейнера есть жёсткий лимит
●
Недостатки:
– Свободная память хоста не используется
– Неиспользуемая память контейнеров не
перераспределяется
9
CleancacheCleancache
●
Инфраструктура для обработки вытесняемых чистых страниц
дискового кэша
– Предоставляет возможность регистрации callback-ов из модулей
ядра
– Является частью “ванильного” ядра Linux
10
2-е приближение: Жесткое разграничение + cleancache2-е приближение: Жесткое разграничение + cleancache
●
У каждого контейнера есть жёсткий лимит
●
Вытесняемые страницы файлового кэша контейнеров
копируются в cleancache
●
Недостатки:
– Свободная память хоста не используется
– Неиспользуемая память контейнеров не перераспределяется
– Cleancache “давит” на память всех контейнеров
11
Soft limitSoft limit
●
Аналог барьера в beancounters – может быть превышен
●
Во время глобальной нехватки памяти:
– в первую очередь выбрасывается память тех контейнеров,
которые превышают свой лимит
– если ни один контейнер не превышает лимита, выбрасывается
память всех контейнеров
●
Является частью “ванильного” ядра Linux
12
3-е приближение: Жесткое разграничение + cleancache + soft limit3-е приближение: Жесткое разграничение + cleancache + soft limit
●
У каждого контейнера есть жёсткий лимит
●
Вытесняемые страницы файлового кэша контейнеров копируются в cleancache
●
У каждого контейнера есть soft limit для защиты от давления cleancache
●
Недостатки:
– Cleancache “давит” на память всех контейнеров
– Soft limit должен меняться во времени непонятным образом
13
Во что выставлять soft limit?Во что выставлять soft limit?
●
Статически: soft limit = hard limit
– Неиспользуемая память контейнеров не перераспределяется
●
Статически: soft limit = memory guarantee
– В Virtuozzo никогда не было гарантий предоставления ресурсов
– Чему должно быть равно значение по умолчанию для гарантии?
– Если 0 (что логично), то по умолчанию получаем “2-е
приближение”
(cleancache “давит” на память всех контейнеров)
●
Динамически: memory guarantee ≤ soft limit ≤ hard limit
14
VCMMD: Virtuozzo Containers Memory Management
Daemon
VCMMD: Virtuozzo Containers Memory Management
Daemon
●
Работает в пространстве пользователя
●
Получает настройки контейнеров от vzctl
●
Наблюдает за состоянием контейнеров
●
Изменяет параметры memory cgroup контейнеров соответственно
текущей ситуации
15
Во что выставлять soft limit?Во что выставлять soft limit?
●
guarantee ≤ soft limit ≤ hard limit
●
soft limit ~ working set size (wss)
●
VCMMD динамически оценивает wss конейнеров на основе
– swapin, refault rate
– memory/swap usage
– memory access pattern
(Documentation/vm/idle_page_tracking.txt)
16
4-е поколение системы управления памятью OpenVZ4-е поколение системы управления памятью OpenVZ
• Ядро
– Групповой контроллер памяти (memory cgroup)
– Два ограничения – жёсткое и мягкое
– Интерфейс cleancache для работы с “выкинутым” дисковым кэшем
• Пространство пользователя – VCMMD
– Один обязательный конфигурационный параметр – размер памяти
контейнера
– Дополнительный параметр – гарантия предоставления памяти
– Динамическая конфигурация лимитов memory cgroup соответственно
текущим запросам контейнеров
17
VCMMD: Преимущества над VSwapVCMMD: Преимущества над VSwap
●
Легко поддерживать, поскольку изменения в ядре ОС
минимальны
●
Легко отлаживать, поскольку вся логика реализована в
пространстве пользователя
●
Возможность менять логику в зависимости от дистрибутива
или системы
●
Гарантия предоставления памяти контейнеру
18
VCMMDVCMMD
●
Исходный код доступен по адресу:
https://src.openvz.org/projects/OVZ/repos/vcmmd
●
Вопросы можно задавать по e-mail:
mailto:vdavydov@odin.com
19
Спасибо за вниманиеСпасибо за внимание

Управление памятью контейнеров в проекте OpenVZ -- Владимир Давыдов

  • 1.
    Управление памятью контейнеров впроекте OpenVZ Управление памятью контейнеров в проекте OpenVZ Владимир Давыдов
  • 2.
    ПланПлан • Введение • Историческийэкскурс • Новая концепция управления ресурсами 2
  • 3.
    ВведениеВведение • Контейнеры потребляютресурсы ОС • Необходим учёт и контроль 3
  • 4.
    1-е поколение: UserBeancounters1-е поколение: User Beancounters • Изначально разрабатывались для upstream Linux, добавлены в Virtuozzo на заре проекта • Процессы объединяются в группы, группа = контейнер • 22 ресурса (количество процессов, открытые файлы, 5 “типов” памяти, ...) • Жесткие ограничения на потребление • Нет явного контроля физической памяти 4
  • 5.
    2-е поколение: SLM2-епоколение: SLM • Разработан для Virtuozzo 3.0 (полностью закрытая разработка) • Попытка отказаться от большого количества параметров – один основной параметр slmmemorylimit – SLM демон жонглирует ограничениями и пытается держать процессы в рамках – множество вспомогательных параметров для тонкой настройки • Также нет контроля за физической памятью 5
  • 6.
    3-е поколение: VSwap3-епоколение: VSwap • OpenVZ 2.6.32, Virtuozzo 4.7, PCS 6 • “Вырос” из memory cgroup для upstream Linux • Основной и единственный ресурс – физическая память – Первое решение, управляющее и физической памятью тоже • За несколько лет версия upstream и наша очень сильно разошлись в деталях – Swap & OOM killer – Использование свободной памяти хоста – Балансировка памяти между контейнерами 6
  • 7.
    4-е поколение: VCMMD4-епоколение: VCMMD • Попытка перестать бесконечно изменять upstream контроллер, но сохранить возможность настраивать поведение ядра для наших клиентов • VCMMD = memory cgroup (upstream kernel) + vcmmd (openvz userspace) – минимум изменений в ядре Linux – бОльшая часть логики – в пространстве пользователя • Один обязательный тип ресурса – физическая память, доступная контейнеру 7
  • 8.
    Управление памятью контейнеров:требуемые эффектыУправление памятью контейнеров: требуемые эффекты • Контейнеры должны “чувствовать” себя как хост с аналогичным количеством памяти • Свободная память хоста (при наличии) должна использоваться для временного хранения выкинутой из контейнеров памяти • Долго неиспользуемая память контейнера должна со временем освобождаться • Короткие всплески в потреблении памяти должны удовлетворяться • Возможность задать “гарантии” предоставления памяти 8
  • 9.
    1-е приближение: Жесткоеразграничение1-е приближение: Жесткое разграничение ● У каждого контейнера есть жёсткий лимит ● Недостатки: – Свободная память хоста не используется – Неиспользуемая память контейнеров не перераспределяется 9
  • 10.
    CleancacheCleancache ● Инфраструктура для обработкивытесняемых чистых страниц дискового кэша – Предоставляет возможность регистрации callback-ов из модулей ядра – Является частью “ванильного” ядра Linux 10
  • 11.
    2-е приближение: Жесткоеразграничение + cleancache2-е приближение: Жесткое разграничение + cleancache ● У каждого контейнера есть жёсткий лимит ● Вытесняемые страницы файлового кэша контейнеров копируются в cleancache ● Недостатки: – Свободная память хоста не используется – Неиспользуемая память контейнеров не перераспределяется – Cleancache “давит” на память всех контейнеров 11
  • 12.
    Soft limitSoft limit ● Аналогбарьера в beancounters – может быть превышен ● Во время глобальной нехватки памяти: – в первую очередь выбрасывается память тех контейнеров, которые превышают свой лимит – если ни один контейнер не превышает лимита, выбрасывается память всех контейнеров ● Является частью “ванильного” ядра Linux 12
  • 13.
    3-е приближение: Жесткоеразграничение + cleancache + soft limit3-е приближение: Жесткое разграничение + cleancache + soft limit ● У каждого контейнера есть жёсткий лимит ● Вытесняемые страницы файлового кэша контейнеров копируются в cleancache ● У каждого контейнера есть soft limit для защиты от давления cleancache ● Недостатки: – Cleancache “давит” на память всех контейнеров – Soft limit должен меняться во времени непонятным образом 13
  • 14.
    Во что выставлятьsoft limit?Во что выставлять soft limit? ● Статически: soft limit = hard limit – Неиспользуемая память контейнеров не перераспределяется ● Статически: soft limit = memory guarantee – В Virtuozzo никогда не было гарантий предоставления ресурсов – Чему должно быть равно значение по умолчанию для гарантии? – Если 0 (что логично), то по умолчанию получаем “2-е приближение” (cleancache “давит” на память всех контейнеров) ● Динамически: memory guarantee ≤ soft limit ≤ hard limit 14
  • 15.
    VCMMD: Virtuozzo ContainersMemory Management Daemon VCMMD: Virtuozzo Containers Memory Management Daemon ● Работает в пространстве пользователя ● Получает настройки контейнеров от vzctl ● Наблюдает за состоянием контейнеров ● Изменяет параметры memory cgroup контейнеров соответственно текущей ситуации 15
  • 16.
    Во что выставлятьsoft limit?Во что выставлять soft limit? ● guarantee ≤ soft limit ≤ hard limit ● soft limit ~ working set size (wss) ● VCMMD динамически оценивает wss конейнеров на основе – swapin, refault rate – memory/swap usage – memory access pattern (Documentation/vm/idle_page_tracking.txt) 16
  • 17.
    4-е поколение системыуправления памятью OpenVZ4-е поколение системы управления памятью OpenVZ • Ядро – Групповой контроллер памяти (memory cgroup) – Два ограничения – жёсткое и мягкое – Интерфейс cleancache для работы с “выкинутым” дисковым кэшем • Пространство пользователя – VCMMD – Один обязательный конфигурационный параметр – размер памяти контейнера – Дополнительный параметр – гарантия предоставления памяти – Динамическая конфигурация лимитов memory cgroup соответственно текущим запросам контейнеров 17
  • 18.
    VCMMD: Преимущества надVSwapVCMMD: Преимущества над VSwap ● Легко поддерживать, поскольку изменения в ядре ОС минимальны ● Легко отлаживать, поскольку вся логика реализована в пространстве пользователя ● Возможность менять логику в зависимости от дистрибутива или системы ● Гарантия предоставления памяти контейнеру 18
  • 19.
    VCMMDVCMMD ● Исходный код доступенпо адресу: https://src.openvz.org/projects/OVZ/repos/vcmmd ● Вопросы можно задавать по e-mail: mailto:vdavydov@odin.com 19
  • 20.