Embed Size (px)
Citation preview
Управление памятью
контейнеров в проекте 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 limit14
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:[email protected]
19
Спасибо за вниманиеСпасибо за внимание
