Сколько RAM нужно для Apache Guacamole

MAATRIX

Guacamole — единственный удалённый рабочий стол, который не просит ставить клиент: открыли вкладку браузера, ввели логин — и вот уже RDP-сессия на Windows-сервере или VNC на Linux-десктопе. Проблема в другом: официальная документация про RAM говорит расплывчато («зависит от нагрузки»), а когда вы арендуете VPS под десяток сотрудников с RDP-доступом, хочется знать хотя бы порядок цифр, а не гадать. Разберём, из чего на самом деле складывается потребление памяти и как посчитать его под свою нагрузку.

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

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

• guacd — демон на C, который держит реальные RDP/VNC/SSH-соединения к целевым машинам, декодирует протокол и превращает его в поток Guacamole-инструкций (по сути — набор тайлов изображения и команд отрисовки) для браузера. Это самый «интересный» с точки зрения памяти компонент, потому что он держит буферы кадров.
• guacamole-client — веб-приложение на Java, которое крутится в Tomcat (или Jetty при --standalone-сборке). Оно отдаёт HTML5/JS-интерфейс, авторизует пользователей и проксирует WebSocket-туннель между браузером и guacd.
• База данных — если вы используете guacamole-auth-jdbc (а не голый user-mapping.xml), нужна MySQL/MariaDB или PostgreSQL: там хранятся пользователи, права, история подключений, иногда — записи сессий.
• Обвязка — nginx/Caddy как reverse proxy перед Tomcat (для SSL и нормальных путей), плюс сама ОС.

Ключевой момент: guacd потребляет память на каждое активное соединение отдельно — это не общий пул, а буфер под конкретную сессию (изображение экрана, промежуточные тайлы, при VNC — ещё и палитра). Tomcat и JVM, наоборот, держат более-менее фиксированный «базовый» объём под кучу (heap) плюс небольшую надбавку на каждую WebSocket-сессию и HTTP-контекст.

Что определяет аппетит guacd: протокол, разрешение, кодирование

Прежде чем давать цифры, важно понять переменные — иначе любая оценка будет гаданием.

• Протокол. RDP через FreeRDP тяжелее VNC: у RDP больше состояния (буфер обмена, перенаправление дисков и звука, глубина цвета управляется сервером), у VNC — по сути голый растровый поток. SSH — самый лёгкий вариант, там просто текстовый терминал, память под guacd для SSH-сессии обычно не превышает нескольких десятков мегабайт.
• Разрешение экрана. Буфер кадра растёт линейно от площади экрана. 1920×1080 в 32 бита — это чуть больше 8 МБ на один полный кадр без сжатия; guacd хранит не один кадр, а несколько промежуточных буферов (текущий + предыдущий для diff-обновлений), так что реальный расход выше номинального размера кадра в 2–4 раза.
• Глубина цвета. 16 бит вместо 32 почти вдвое уменьшает буферы — актуально для VNC-серверов, где это настраивается явно.
• Динамика картинки. Статичный рабочий стол (текстовый редактор, терминал) почти не создаёт нагрузки — Guacamole пересылает только изменившиеся тайлы. Видео, скролл, drag-and-drop окон — это постоянный поток новых тайлов, и здесь растёт не столько память, сколько CPU и сеть, но пиковое потребление памяти тоже подскакивает из-за очередей на кодирование.
• Доп. функции RDP. Проброс аудио, буфера обмена, дисков (drive-path) добавляют по несколько мегабайт на сессию, но не критично.

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

Сколько нужно для одного-двух пользователей

Для персонального use case — например, вы хотите иметь «прыжковый сервер» с доступом по RDP к своей рабочей машине из любой точки — хватает совсем скромного VPS.

Из этих 2 ГБ примерно распределение такое (ориентир): 300–400 МБ ОС и системные службы, 400–600 МБ JVM/Tomcat (heap -Xmx512m с запасом), 100–300 МБ на guacd под активную RDP-сессию в Full HD, 150–250 МБ MySQL/MariaDB, если используете JDBC-аутентификацию (для одного пользователя часто хватает user-mapping.xml без базы вообще — тогда экономите эти 200 МБ). Остаётся запас на файловый кэш и всплески. На 1 ГБ RAM Guacamole тоже запустится, но без свопа первая же RDP-сессия в высоком разрешении рискует упереться в OOM killer — не рекомендую.

Расчёт под команду: 5–20 одновременных сессий

Когда Guacamole используется как корпоративный шлюз для нескольких сотрудников (техподдержка, удалённые рабочие места, доступ подрядчиков к прод-серверам), логика расчёта простая: базовая нагрузка + переменная часть на сессию.

Грубая формула для ориентира:

RAM ≈ ОС (400 МБ) + JVM heap (768–1024 МБ) + БД (300–500 МБ)
      + N_сессий × (30–150 МБ)

Где 30 МБ — это лёгкая SSH/терминальная сессия, а 150 МБ — активная RDP-сессия в Full HD с проброшенным звуком и буфером обмена под нагрузкой (видео, много перерисовок). Для смешанной нагрузки удобнее закладывать 60–80 МБ на сессию как среднее.

Если у вас не просто гейтвей, а ещё и запись сессий (recording-path в guacd) — учитывайте, что это в первую очередь нагрузка на диск и I/O, а не на RAM, но буферы записи тоже откусывают по несколько мегабайт на активную сессию.

Отдельный случай — если Guacamole стоит перед Windows Server с несколькими одновременными RDP-пользователями. Тут стоит сразу прикинуть и лицензирование RDS CAL на стороне Windows, это отдельный вопрос от размера VPS под сам Guacamole.

docker-compose с лимитами памяти — рабочий пример

Официальный docker-compose.yml из документации Guacamole не задаёт лимиты памяти вообще — контейнеры могут расти без ограничений и в момент пиковой нагрузки утащить весь сервер в своп или OOM. На проде лимиты нужно выставлять явно.

version: "3.8"

services:
  guacd:
    image: guacamole/guacd:1.5.5
    restart: unless-stopped
    mem_limit: 1g
    mem_reservation: 256m
    volumes:
      - ./drive:/drive
      - ./record:/record

  guacamole:
    image: guacamole/guacamole:1.5.5
    restart: unless-stopped
    depends_on:
      - guacd
      - mysql
    environment:
      GUACD_HOSTNAME: guacd
      MYSQL_HOSTNAME: mysql
      MYSQL_DATABASE: guacamole_db
      MYSQL_USER: guacamole_user
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
      # JVM heap — ключевой параметр для памяти Tomcat
      JAVA_OPTS: "-Xms256m -Xmx768m"
    mem_limit: 1g
    mem_reservation: 384m
    ports:
      - "127.0.0.1:8080:8080"

  mysql:
    image: mariadb:11
    restart: unless-stopped
    environment:
      MARIADB_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MARIADB_DATABASE: guacamole_db
      MARIADB_USER: guacamole_user
      MARIADB_PASSWORD: ${MYSQL_PASSWORD}
    mem_limit: 512m
    mem_reservation: 128m
    volumes:
      - ./mysql-data:/var/lib/mysql

Пара нюансов:

• JAVA_OPTS с -Xmx — это потолок кучи JVM, но реальный процесс Tomcat съест ещё немного сверху (metaspace, стеки потоков, off-heap буферы под WebSocket) — закладывайте mem_limit контейнера примерно на 250–300 МБ больше, чем -Xmx, иначе получите OOMKilled прямо на старте под нагрузкой.
• guacd официально не поддерживает лимит памяти per-connection через переменные окружения — единственный способ ограничить его аппетит — это mem_limit контейнера целиком плюс дисциплина по разрешениям экрана на стороне пользователей.
• Если сессий много и часть из них тяжёлые RDP, вынесите MySQL на отдельный volume с достаточным диском — история подключений (guacamole_connection_history) растёт быстро при активном использовании.

Подробнее про то, как вообще выставлять mem_limit/mem_reservation в docker-compose и что будет при их превышении, — в статье про лимиты CPU и памяти в Docker. Про установку самой MySQL/MariaDB под backend — в пошаговой инструкции по MySQL на VPS.

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

Расчёты выше — стартовая точка, а не гарантия. Дальше нужно смотреть на реальные цифры на вашем сервере.

# Живое потребление по контейнерам
docker stats --no-stream

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

# Что происходит внутри контейнера guacd в моменте активной сессии
docker exec guacd ps aux --sort=-rss | head

Если видите, что guacd регулярно упирается в лимит при активных RDP-сессиях — варианты:

1. Снизить разрешение для сессий, где Full HD не нужен (типовая офисная работа отлично живёт на 1366×768).
2. Отключить лишние редиректы — звук и буфер обмена нужны не всем, каждый выключенный канал немного снижает память и трафик.
3. Ограничить количество одновременных подключений на уровне организации в Guacamole (Connection → Concurrency), чтобы не давать серверу поймать всплеск сразу от всех пользователей.
4. Добавить своп как страховку от OOM, а не как основной ресурс — Guacamole не любит, когда активные буферы кадров уходят в своп, это ощутимо тормозит перерисовку экрана. Как правильно посчитать размер свопа под конкретный объём RAM — в статье про правильный размер swap для VPS.
5. Масштабировать guacd горизонтально — на высокой нагрузке несколько инстансов guacd за балансировщиком лучше одного разросшегося контейнера, потому что изоляция сессий снижает риск, что одна тяжёлая сессия завалит остальные.

Если вы даёте пользователям RDP-доступ во внешний мир не только через Guacamole, а параллельно держите прямой RDP-порт для части сценариев — почитайте про безопасный доступ к RDP через WireGuard: для случаев, где HTML5-гейтвей избыточен, это часто более простое и лёгкое по ресурсам решение.

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