Одна из первых проблем, с которыми вы сталкиваетесь, когда решаете использовать «неограниченную память» в облаке, заключается в том, что современные операционные системы не готовы к «неограниченной памяти».
Это связано с дисковым кешем.
Ядро захватывает всю свободную кэш-память.
Если есть дисковые операции и свободная память, кэш будет расти.
В случае сервера с исключительно используемой памятью это благо, однако, если речь идет о том, что все мегабайты платные, то платить за дисковый кэш объемом 10-20ГБ откровенно не хочется.
Я пытался найти способ ограничить размер дискового кэша для Linux, но нашел только странный патч от 2003 года (который, естественно, не был взят в основную ветку).
Получается, что чем больше работает гость, тем больше памяти занимает его ядро из своей (неограниченной) емкости.
В результате получается, что если вообще не ограничивать систему, то за очень короткое время она вырастает либо до размера дисковых устройств (спасибо, нет дискового кэша большего размера диска), либо до размера максимальный объем памяти, доступный на платформе.
Заметим, что в этих условиях все технологии дают сбой — и сжатие памяти, и дедупликация страниц памяти (у каждой ВМ свой кэш).
С этой проблемой сталкивается любая система виртуализации.
Ниже мы опишем варианты решения с прицелом на Xen Cloud Platform. Варианты решений Я вижу три варианта решения проблемы:
- Механизм ксенбаллона, используемый в Xen. В ядре специальный драйвер при обращении изнутри самой системы резервирует память у операционной системы и отдает ее гипервизору («освобождает»).
При необходимости его просят «забрать обратно» — и он забирает (т. е.
возвращает в систему).
Фактически, используемая всплывающая память занята с точки зрения гостя и свободна с точки зрения гипервизора.
Когда память забирается у гипервизора, она становится свободной для гостя и занятой для гипервизора.
- Внешний механизм регулирования доступной памяти.
От раздувания он отличается только тем, что решение о выделении/удалении памяти принимается не приложением, выполняющим xenballoon, а внешней системой управления.
Дзен уже давно позволяет на лету менять объём доступной памяти для гостевых машин (сколько установишь, столько и будет доступно).
Вплоть до забавной ситуации, когда дают памяти меньше, чем занято на данный момент. В этом случае на помощь приходит oom_killer внутри гостевой системы (а лучше этого не делать)
- Написание патча ядра, который бы ограничивал размер дискового кэша определенным фиксированным значением.
Но это требует существенных изменений в коде ядра, а, возможно, и пересмотра всего механизма работы с памятью.
Для меня этот путь.
несколько тернист. Первый и второй действительно работают сейчас.
Однако у них есть один существенный недостаток: в такой системе свободная память добавляется/удаляется асинхронно с запросами.
Грубо говоря, если у гостевой системы есть 200 МБ свободной памяти, а приложение запросило 500, то в выделении ей будет отказано.
Потому что в ядре нет лишних 300Мб.
А демон (или внешний монитор) узнает об этой проблеме после обработки запроса на выделение памяти.
.
Казалось бы, очевидное решение: пусть ядро при запросе свободной памяти тянет интерфейс.
Однако в этой ситуации одно и то же ядро будет бесконечно съедать всю доступную память для дисковых кэшей, потому что ни один запрос памяти не останется без ответа.
Однако ситуация не безнадежна.
Во-первых, приложения обычно не съедают память такими кусками.
Обычно это постепенное (точнее, достаточно быстрое, но меньшими порциями) выделение памяти разным приложениям по мере увеличения нагрузки.
В этой ситуации каждый раз, когда в гостевой системе остается слишком мало памяти, демон в гостевой системе или внешний монитор может добавить больше памяти.
Менять Во-вторых, есть файл подкачки.
Если приложение запросило 200 МБ свободной памяти на 500, то ему дадут 200 МБ свободной памяти, а 300 МБ малоиспользуемых данных закинут в swap и отдадут необходимое количество.
И тогда этот же монитор, видя нехватку памяти, добавит гостевой системе еще 500МБ, чтобы она могла продолжать спокойно работать.
Так как в своп будут заброшены наименее релевантные данные, то есть большая вероятность, что доступ к ним будет очень и очень редким (или вообще никогда не произойдет).
Благодаря «демпферу» в виде файла подкачки объективно можно обеспечить память без ситуаций оом (нехватки памяти), но и без прожорливого кэша в десятки гигабайт. Итоговая схема выглядит так: Для гостевой системы выделяется определенный объем свободной памяти, больший, чем объем занимаемой памяти.
Эта память используется в качестве дискового кэша разумного размера (она по-прежнему необходима даже на гостевых виртуальных машинах, поскольку именно они лучше знают, какие страницы диска важнее).
Независимо от того, сколько памяти использует приложение, свободная область всегда остается неизменной (за исключением незначительных колебаний из-за асинхронного распределения памяти приложения и распределения памяти гостевой ОС).
Свободная память Отдельная задача — определение свободной памяти гостя.
Как мы можем сделать это «снаружи»? Скажу сразу — никак (если не рассматривать варианты грязного копания в мозгах гостевого ядра грубыми пальцами гипервизора).
Невозможно понять, что страница «а» чистая (свободна), а страница «б» грязная (занята).
В XCP (Xen Cloud Platform) единственным методом определения свободной памяти является агент (демон), который сообщает гипервизору, сколько памяти свободно.
На основе этой информации гипервизор решает, сколько памяти добавить и удалить в гостевой системе.
Как это выглядит из гостевой системы? Она запускает простой скрипт, который через определенные промежутки времени записывает данные о свободной памяти в xenstore (канал связи между гипервизором и гостевой системой) (при этом записывает текущий IP-адрес и версию ОС).
Система управления облаком просматривает эту информацию и добавляет/удаляет гостевую память.
С точки зрения гостя, объем свободной памяти практически всегда остается одинаковым, независимо от того, сколько памяти заняли приложения; эта память используется для дискового кэша.
В случае каких-то спонтанных всплесков (запрос 1ГБ за раз - не очень типичное поведение) случаются кратковременные моменты подкачки, однако на данный момент (тестирование еще не началось) полагаю, что эти случаи будут единичными и нехарактерными .
С точки зрения гипервизора, объём памяти, используемой гостевой машиной, меняется, и он меняется в зависимости от того, сколько памяти фактически используется в госте.
Что произойдет, если гость решит «пошалить» и изменит код демона, сообщающего о свободном пространстве памяти, или просто отключит его? Для хостера - ничего плохого.
Он просто перестанет получать информацию о свободной памяти (и перестанет ее регулировать).
Если данные написаны неправильно, то это либо отнимет у гостя много памяти (гость мог бы добиться этого сам, добавив дополнительные приложения), либо отдаст ему много памяти - но гость платит по потреблению.
Так что я не думаю, что кто-то из продуктовых компаний решит серьёзно пошалить с этим сервисом.
Я до сих пор сомневаюсь, какой механизм управления памятью лучше — гостевой демон (xenballooning) или внешний монитор.
Теги: #Виртуализация #Облачные вычисления #RAM #Xen Cloud Platform
-
Знакомство С Tesla Model 3
19 Oct, 24 -
Обновление Интерфейса Google Картинок
19 Oct, 24 -
Умная Перьевая Ручка Neo Smartpen N2
19 Oct, 24 -
Решение Суда. Ржд Против Apple
19 Oct, 24 -
Подробности Секретной Сделки Opera Software
19 Oct, 24 -
Несколько Мыслей О Блогах
19 Oct, 24 -
Веб-Крокодил
19 Oct, 24 -
Хромбуки В России
19 Oct, 24
