Сколько RAM нужно для Kasm Workspaces

MAATRIX

Kasm Workspaces обещает красивую вещь: любой рабочий стол или приложение в изолированном Docker-контейнере, доступное из обычной вкладки браузера без единого локального клиента. Но стоит открыть документацию по системным требованиям — и там сплошные «от 8 ГБ» без внятного объяснения, что именно ест эту память и как она растёт с числом пользователей. Разберём архитектуру Kasm по частям и посчитаем, сколько RAM реально нужно — от сервера для одного технаря до инфраструктуры на полсотни параллельных сессий.

Из чего состоит Kasm Workspaces и куда уходит память

Kasm — это не один процесс, а набор сервисов плюс контейнеры пользовательских сессий, и память расходуется на два принципиально разных уровня.

Инфраструктурный уровень (в single-server установке всё крутится на одной машине как набор Docker-контейнеров, поднятых через install.sh):

• kasm_db — PostgreSQL, хранит пользователей, права, конфигурацию образов, историю сессий.
• kasm_api — управляющий API, обрабатывает запросы на создание/остановку сессий, авторизацию, RBAC.
• kasm_manager — веб-интерфейс администратора и пользовательский лаунчер («рабочий стол» со списком доступных приложений).
• kasm_proxy — nginx-based прокси, который терминирует TLS и маршрутизирует WebSocket-трафик KasmVNC между браузером и контейнером сессии.
• kasm_agent — компонент, который физически поднимает Docker-контейнер под каждую новую сессию на конкретном узле (в single-server агент живёт на том же хосте, в распределённой установке — на отдельных worker-нодах).
• kasm_share — опциональный сервис для share-ссылок на сессию без авторизации.

Уровень пользовательских сессий — это отдельные Docker-контейнеры, по одному на каждого активного пользователя, каждый со своим образом (браузер, полноценный Linux-десктоп, конкретное приложение вроде GIMP или VS Code). В отличие от Guacamole, где guacd лишь ретранслирует чужой RDP/VNC-поток, в Kasm сам рабочий стол или браузер выполняется внутри контейнера — то есть память тратится не на буфер кадра, а на реальный рендеринг: X-сервер, оконный менеджер, сам браузер или приложение со всеми его вкладками и расширениями.

Именно поэтому Kasm по натуре прожорливее классических HTML5-гейтвеев: вы не удалённо подключаетесь к чужому десктопу, а поднимаете новый десктоп с нуля под каждую сессию.

Базовая инфраструктура: сколько нужно ещё до первой сессии

По официальным рекомендациям Kasm для single-server установки закладывают минимум 4 vCPU и 8 ГБ RAM ещё до того, как в системе появится хоть один активный пользователь. Это не маркетинговый запас — именно столько реально уходит на связку PostgreSQL + API + Manager + Proxy + Agent под управлением docker compose, плюс сама ОС.

Из этих 8 ГБ базовая инфраструктура (без сессий) обычно занимает ориентировочно 2.5–3.5 ГБ:

Оставшиеся 4.5–5.5 ГБ из рекомендованных 8 ГБ — это как раз запас под одну-две пользовательские сессии, а не свободный воздух. Если вы разворачиваете Kasm ради одного-двух пользователей (например, изолированный браузер для просмотра подозрительных ссылок или разовый доступ подрядчика), 8 ГБ — реалистичный минимум, из которого урезать особо некуда: часть сервисов не запустится штатно при агрессивном ограничении памяти контейнеров.

Сколько RAM ест одна пользовательская сессия

Это самая изменчивая часть расчёта, потому что Kasm поставляется с десятками готовых образов — от лёгкого одиночного браузера до тяжёлого Linux-десктопа с полным набором софта. Дальше — ориентировочные диапазоны по типам образов, которые стоит проверить на своей нагрузке, а не воспринимать как гарантию.

Главный фактор роста внутри одного типа образа — не сам факт запуска приложения, а то, что происходит внутри: количество открытых вкладок браузера, включённое аппаратное ускорение видео, разрешение виртуального экрана (KasmVNC, как и любой протокол удалённого рабочего стола, требует больше памяти под кадровые буферы на Full HD и выше, чем на 1366×768). Статичная сессия с текстовым редактором почти не растёт со временем, а сессия с активным видео или тяжёлым веб-приложением может за час работы вырасти в полтора-два раза от стартового значения — это стоит закладывать не как разовое число, а как диапазон.

Точных цифр «X МБ на образ Y» вендор не публикует как гарантию — это средние значения из практики эксплуатации, и на вашей версии Kasm с вашим набором расширений и сайтов они вполне могут отличаться в обе стороны.

Расчёт под команду: от одного пользователя до полусотни сессий

Формула для прикидки простая — база под инфраструктуру плюс переменная часть на каждую активную сессию:

RAM ≈ Инфраструктура Kasm (3–4 ГБ) + N_сессий × RAM_на_сессию

Где RAM_на_сессию берётся из таблицы выше в зависимости от того, какими образами реально пользуется команда — если это смесь браузера и лёгкого десктопа, для грубой прикидки удобно закладывать 1.5 ГБ на сессию как усреднённое значение.

С ростом числа одновременных сессий имеет смысл переходить с single-server установки на распределённую архитектуру Kasm: отдельный сервер под базу и управляющие сервисы, отдельные agent-ноды под контейнеры сессий. Это не столько экономит суммарную RAM, сколько защищает от ситуации, когда один разросшийся десктоп через OOM killer роняет заодно и kasm_db, а вместе с ним — все активные сессии остальных пользователей.

Если вы прикидываете, что выгоднее — Kasm с полными десктопами в контейнерах или классический HTML5-гейтвей поверх уже существующих RDP/VNC-серверов, — сравнение по памяти и архитектуре стоит смотреть отдельно: у Guacamole совсем другая модель потребления, подробности в статье сколько RAM нужно для Apache Guacamole.

Лимиты памяти на сессию: как не дать одному пользователю съесть весь сервер

По умолчанию Docker-контейнер сессии Kasm не ограничен по памяти — активная вкладка с утечкой памяти в браузере или тяжёлый рендеринг в десктопном приложении способны утащить в своп весь хост, если не выставить лимиты явно.

Ограничения задаются на уровне образа workspace в админ-панели Kasm (Admin → Workspaces → редактирование образа → поле памяти) либо напрямую через Docker resource limits, если вы кастомизируете конфигурацию агента:

# Пример ограничения ресурсов для кастомного workspace-образа
# в конфигурации агента Kasm (docker run параметры)
--memory="2g"
--memory-swap="2g"
--cpus="2"

Пара практических нюансов:

• Лимит памяти на образ стоит выставлять с запасом относительно наблюдаемого пикового потребления — если жёстко зажать контейнер вплотную к среднему значению, активный пользователь будет упираться в OOM внутри собственной сессии при обычной работе, а не при аномалии.
• --memory-swap, равный --memory, отключает своп для контейнера сессии — это осознанный выбор в пользу быстрого предсказуемого OOM вместо тормозящей деградации, когда активные буферы X-сервера уходят в своп на хосте.
• На самом хосте всё равно стоит держать разумный своп как страховочную сетку для инфраструктурных сервисов (PostgreSQL, API), а не для сессий — подробнее о том, как считать нужный объём, в статье про правильный размер swap для VPS.

Общие принципы работы с mem_limit/mem_reservation в Docker и что происходит при их превышении разобраны в статье про лимиты CPU и памяти в Docker — они применимы и к инфраструктурным контейнерам самого Kasm, не только к сессиям.

Как замерить реальное потребление и что делать при нехватке RAM

Расчёты выше — стартовая точка для выбора тарифа, а не готовый ответ. На практике смотреть нужно на реальные цифры под вашей нагрузкой.

# Общая картина по хосту
free -h

# Потребление по всем контейнерам Kasm, включая активные сессии
docker stats --no-stream

# Только сессии пользователей — контейнеры Kasm обычно
# именуются с префиксом kasm или содержат ID сессии
docker stats --no-stream $(docker ps --filter "name=kasm" -q)

# Проверка срабатывания OOM killer
dmesg | grep -i oom

Дополнительно у Kasm есть встроенный мониторинг в админ-панели (Admin → Analytics), который показывает загрузку по нодам и сессиям без выхода в консоль — на нём удобно смотреть тренд за неделю, а не разовый снимок.

Если сервер регулярно упирается в лимит памяти:

1. Урезать разрешение виртуального экрана для сессий, где Full HD не нужен — офисные задачи прекрасно живут на 1366×768, и это заметно снижает буферы KasmVNC.
2. Ограничить набор доступных образов — если пользователям хватает изолированного браузера, не давайте им по умолчанию тяжёлый Linux-десктоп «на всякий случай».
3. Включить автоматическое завершение неактивных сессий (idle timeout в настройках workspace) — забытые открытые сессии продолжают жрать память, даже если ими никто не пользуется.
4. Вынести агентов на отдельные ноды, если single-server установка начала упираться в потолок — это стандартный путь роста для Kasm при увеличении числа пользователей.

Если нехватка памяти проявляется не только в Kasm, а системно по всему серверу, — общий план действий (что смотреть первым, как найти виновника, когда действительно нужен апгрейд, а когда хватит тюнинга) разобран в статье что делать при нехватке RAM.

Частые вопросы