Управление памятью контейнеров в проекте OpenVZ Владимир Давыдов https://events.yandex.ru/events/yagosti/19-september-2015-linux/

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

2. ПланПлан
• Введение
• Исторический экскурс
• Новая концепция управления ресурсами
2

3. ВведениеВведение
• Контейнеры потребляют ресурсы ОС
• Необходим учёт и контроль
3

4. 1-е поколение: User Beancounters1-е поколение: 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 Containers Memory 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. Спасибо за вниманиеСпасибо за внимание