kostjn писал(а):
Вы можете объяснить как в vz считается память? Было бы очень интересно сравнить подходы.
я не являюсь разработчиком openvz, но интересовался этой темой в целях администрирования.
Весьма много инфы можно найти сдесь:
http://wiki.openvz.org
В частности вам будет интересно посмотреть это:
http://wiki.openvz.org/UBC_systemwide_configuration
Также, по поиску в гугле:
OpenVZ Management of System Resources type:pdf
virtuozzo over commitment accounting
Вот в этом гуиде достаточно фундаментально изложена тема ресурсов и менеджмента опенвз.
http://www.altaway.com/resources/vz/VzLinuxUBCMgmt.pdf
Основная загвоздка в том, что называется термином memory overcommitment, т.е. на пальцах когда приложение запрашивает у системы памяти больше, чем есть в наличии ОЗУ.
Система выделяет эти блоки памяти (с учетом свапа), но они часто не используются. (В линуксе посмотреть вывод free -m) Это хорошо работает на Hardware Node, но как быть с виртуалками в условиях легкой (os-level) виртуализации? В виртуозо решение простое, понятие swap немного расплывчато, реально виртуалки будут использовать свап только в том случае, когда в Hardware Node закончится оперативная память полностью. В иных случаях не будут никогда. И вообщемто это правильно. Т.к. дисковый I\O - та вещь которая максимально убивает сервер. Просто следует учитывать, что память в контейнерах виртуозо - это память без оверкоммитмента. Гигабайт - это гигабайт, и если ява при старте попытается аллоцировать больше, то система ей не даст этого сделать. А в реальной системе с гигом озу, ява запросто запустится (благодаря оверкоммитменту)
В VDS_manager, насколько я понимаю, концепция немного другая. По крайней мере в том контейнере что у меня был, я видел в топе колонку swap ( свап персональный для контейнера). И колонка с памятью была тоже одна. Т.е. вся память и wired и cached,buffers, etc считалась как Active.
Но мне такой подход крайне не нравится. Получается что если контейнеру выделить мало озу (скажем, метров 200) и запустить на нем много приложений то они начнут юзать свап, даже без оглядки на то что в системе еще полно свободной памяти. В результате маленький контейнер сможет положить дисковым I\O большую систему.
Это может быть хорошо для end-users, они не будут получать "can not allocate memory" если их приложение попытается аллоцировать больше 200м, но это плохо для системы, т.к. она уйдет в свопинг, нафик нафик короче такой расклад.
PS. наверно стоит сфокусироваться еще больше, если вы сможете хотябы протолкнуть cpu limits per jail до продакшин уровня, то мягко говоря "Родина вас не забудет", и тысячи людей будут благодарны. В вышеприведенных линках на виртуозо описаны также концепции распределения вычислительных ресурсов. Мне кажется они могут вам помочь. Парралельс очень давно и мощно занимается данной темой, и мне кажется что у них OS-based виртуализация реализована достаточно хорошо.
.
