Сколько RAM нужно для RustDesk

MAATRIX

RustDesk — открытая альтернатива TeamViewer и AnyDesk, и главный аргумент в её пользу — не только бесплатность, а возможность поднять собственный сервер и не зависеть от чужой инфраструктуры (и чужих лимитов на бесплатном тарифе). Проблема в том, что официальная документация про требования к серверу почти ничего не говорит — «работает на Raspberry Pi» и всё. Если вы арендуете VPS специально под RustDesk-сервер для команды из десяти человек, хочется понимать порядок цифр заранее, а не методом проб. Разберём, из чего складывается память сервера RustDesk и сколько её реально нужно.

Из чего состоит сервер RustDesk

В отличие от Guacamole или Apache Guacamole с их связкой Java + Tomcat + СУБД, серверная часть RustDesk — это два бинарника на Rust, и уже одно это многое объясняет про память.

• hbbs (ID/rendezvous server) — сервер идентификации и обнаружения. Хранит соответствие ID устройства и его текущего сетевого адреса, обслуживает handshake между клиентом и хостом, пытается установить прямое P2P-соединение (NAT hole punching). Если это удаётся — дальнейший трафик идёт мимо сервера напрямую между клиентами, и hbbs в передаче данных не участвует вообще.
• hbbr (relay server) — сервер-ретранслятор. Включается только тогда, когда прямое P2P-соединение не удалось пробить (симметричный NAT, жёсткий файрвол на одной из сторон) — тогда весь трафик сессии идёт через hbbr, и здесь память уже зависит от активности сессий, а не только от их числа.
• База данных — по умолчанию hbbs использует встроенный SQLite (файл db_v2.sqlite3), внешняя СУБД не нужна вообще. Это отличает RustDesk от того же Guacamole, где MySQL — типовая часть стека.
• Веб-консоль (опционально) — если вы разворачиваете не голый hbbs/hbbr, а полноценную панель управления (например, rustdesk-server-pro), добавляется ещё один процесс, который ест заметно больше — это отдельная история за рамками базовой связки.

Ключевой практический вывод: если у вас в основном P2P-сценарии (оба устройства не за симметричным NAT, что на практике — большинство домашних роутеров и почти все облачные VPS), hbbr почти не нагружается, и сервер целиком может месяцами жить в 300–500 МБ RAM даже под сотню зарегистрированных ID.

Что определяет реальный расход памяти

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

• Доля P2P vs relay-трафика. Это главный фактор. hbbs почти не расходует память на сам факт соединения — он лёгкий диспетчер. hbbr держит буферы под каждую активную ретранслируемую сессию, и чем таких сессий больше одновременно, тем выше пик.
• Число зарегистрированных ID. Каждая запись в SQLite — это несколько сотен байт (ID, публичный ключ, последний известный адрес). Даже 10 000 устройств — это единицы-десятки мегабайт на базу, не больше.
• Разрешение экрана и битрейт кодирования. RustDesk использует H.264/H.265/VP9 в зависимости от настроек и доступности аппаратного кодирования на клиенте — сам сервер видео не декодирует и не перекодирует, он просто пересылает поток байтов через hbbr, поэтому разрешение влияет в основном на сетевой трафик, а не на память сервера. Это принципиальное отличие от Guacamole, где guacd именно декодирует протокол на сервере.
• Одновременные relay-сессии. Каждая активная сессия через hbbr держит сетевые буферы на чтение/запись с обеих сторон (клиент и хост) — это, по практике эксплуатации, порядка единиц мегабайт на сессию, а не десятков, как в случае с полноценным протокольным брокером.
• Passwordless-режим и постоянные ID-сессии. Если у вас включены постоянные соединения для мониторинга (RustDesk как agent для удалённого IT-обслуживания парка машин), количество долгоживущих подключений к hbbs растёт, но каждое из них — это просто запись в таблице соединений, не тяжёлый процесс.

Точных официальных бенчмарков по МБ-на-сессию проект не публикует — цифры ниже это ориентировочные диапазоны из практики самостоятельного хостинга сообщества, у вас в конкретной сети с конкретной долей relay-трафика они могут отличаться заметно.

Сколько нужно для личного использования и небольшой команды

Для сценария «я и пара моих устройств» или «небольшая команда до 10–15 человек, которая ставит RustDesk вместо TeamViewer ради независимости от чужого сервера» требования минимальные.

Из этого объёма реальный расход: 100–150 МБ ОС и системные службы, 20–50 МБ на сам процесс hbbs в простое, 15–30 МБ на hbbr вне активной ретрансляции, плюс копеечный SQLite-файл. Остальное — запас под всплески, когда несколько сессий одновременно упираются в relay из-за NAT. Официальные примеры установки RustDesk-сервера регулярно упоминают запуск даже на Raspberry Pi с 512 МБ или 1 ГБ RAM — это не маркетинг, процесс действительно компактный, потому что написан на Rust без JVM и без тяжёлого веб-фреймворка.

На 512 МБ сервер запустится и будет стабильно работать для личного использования, но если параллельно на той же машине крутится что-то ещё (панель управления, обратный прокси) — лучше взять 1 ГБ с запасом, чтобы не упереться в OOM killer на всплеске relay-сессий.

Расчёт под команду: 20–100+ пользователей и relay-нагрузку

Когда RustDesk используется как корпоративный инструмент удалённого доступа — техподдержка обслуживает парк машин клиентов, у сотрудников постоянные ID для доступа к рабочим станциям — картина меняется, потому что доля сессий, которым не удаётся пробить NAT напрямую, растёт вместе с числом пользователей за разными провайдерами и офисными файрволами.

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

RAM ≈ ОС (200 МБ) + hbbs база (50–100 МБ)
      + N_активных_relay_сессий × (3–8 МБ)

Где 3 МБ — это лёгкая сессия с низким битрейтом (текстовая работа, статичный экран), а 8 МБ — активная сессия с видео/анимацией и включённой передачей звука и файлов. Практика показывает, что доля сессий, реально идущих через relay, а не P2P, в корпоративных сетях с NAT составляет обычно 20–40% от общего числа одновременных подключений — закладывайте это в расчёт, а не считайте, что через hbbr идёт всё.

Отдельно стоит учитывать сеть, а не только память: hbbr гоняет через себя весь трафик relay-сессий, и на активных видеосессиях счёт может идти на десятки Мбит/с суммарно — при большом числе одновременных пользователей вы скорее упрётесь в канал и CPU, чем в RAM. Если планируете обслуживать десятки одновременных relay-сессий постоянно, разумно смотреть не только на объём памяти, но и на аренду VPS в США или UK с хорошим сетевым каналом и оплатой картой РФ или криптой.

Установка и docker-compose с лимитами памяти

Самый предсказуемый способ развернуть hbbs и hbbr — через Docker, официальный образ rustdesk/rustdesk-server поддерживает оба режима одним образом с разными командами запуска.

version: "3.8"

services:
  hbbs:
    image: rustdesk/rustdesk-server:latest
    container_name: hbbs
    restart: unless-stopped
    command: hbbs -r relay.example.com:21117
    ports:
      - "21115:21115"
      - "21116:21116/tcp"
      - "21116:21116/udp"
      - "21118:21118"
    volumes:
      - ./data:/root
    mem_limit: 512m
    mem_reservation: 128m
    networks:
      - rustdesk-net

  hbbr:
    image: rustdesk/rustdesk-server:latest
    container_name: hbbr
    restart: unless-stopped
    command: hbbr
    ports:
      - "21117:21117"
      - "21119:21119"
    volumes:
      - ./data:/root
    mem_limit: 1g
    mem_reservation: 128m
    networks:
      - rustdesk-net

networks:
  rustdesk-net:
    driver: bridge

Пара нюансов из практики:

• Порт 21116 нужен и по TCP, и по UDP — hbbs использует UDP для части handshake-логики (hole punching), если открыть только TCP, NAT traversal будет работать хуже и доля relay-сессий вырастет сама собой.
• -r relay.example.com:21117 в команде hbbs — адрес, который сервер сообщает клиентам как relay-сервер. Если hbbs и hbbr крутятся на одном хосте, указывайте публичный домен или IP этого хоста, не localhost и не имя контейнера.
• Каталог ./data держит id_ed25519/id_ed25519.pub (ключевая пара сервера, критична для доверия клиентов — при потере все клиенты придётся перенастраивать на новый публичный ключ) и файл SQLite — убедитесь, что он попадает в бэкап.
• mem_limit для hbbr я закладываю больше, чем для hbbs, с запасом на всплеск relay-сессий — при статистически низкой доле relay-трафика можно смело сузить его до 512m тоже.

Про сам механизм mem_limit/mem_reservation в docker-compose и что происходит при их превышении — подробно в статье про лимиты CPU и памяти в Docker.

Как замерить реальное потребление и куда смотреть при проблемах

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

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

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

# Сколько активных TCP-соединений держит hbbr прямо сейчас —
# грубый индикатор нагрузки relay
ss -tn state established '( dport = :21117 or sport = :21117 )' | wc -l

# Логи hbbs/hbbr на предмет ошибок и переподключений
docker logs hbbs --tail 100
docker logs hbbr --tail 100

Если видите, что память растёт и не отпускается со временем, а не только на пиках, — это чаще не утечка в самом hbbs/hbbr (Rust здесь по конструкции экономнее управляемых рантаймов вроде JVM), а следствие того, что SQLite-файл db_v2.sqlite3 разрастается без очистки старых записей — раз в несколько месяцев стоит проверять его размер.

Что реально снижает потребление:

1. Максимизировать долю P2P. Откройте UDP 21116 корректно (частая причина, по которой NAT traversal не срабатывает и всё уходит на relay), а на стороне клиентов, где возможно, настройте port forwarding или UPnP.
2. Разнести hbbs и hbbr по разным контейнерам с индивидуальными лимитами (как в примере выше) — так пиковая нагрузка на relay не утащит за собой сервер идентификации, от которого зависят все клиенты, даже P2P.
3. Не открывать сервер публично без пароля/ключа. Заброшенный открытый hbbs рано или поздно ловит сканеры и мусорные подключения — лишняя нагрузка на память и CPU. Если доступ нужен только своим устройствам, логично спрятать сервер за VPN — например, через WireGuard, тогда порты RustDesk вообще не торчат наружу.
4. Держать своп как страховку, а не основной ресурс — на бюджетных VPS своп сглаживает редкие всплески, но постоянная работа в свопе означает задержки в передаче кадров экрана, что для remote desktop особенно заметно. Как посчитать правильный размер — в статье про размер swap для VPS.

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