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

MAATRIX

Если вам нужен свой сервер календарей и контактов — синхронизировать события между телефоном, ноутбуком и рабочим столом без Google или iCloud — первая мысль часто звучит как «поднять Nextcloud». Но Nextcloud под задачу «просто CalDAV и CardDAV» — это PHP-FPM, MySQL или PostgreSQL, Redis для кеша и сотни мегабайт RAM в простое ради функций, которые вам не нужны. Radicale решает ровно эту задачу — синхронизацию календарей и адресных книг по открытым протоколам CalDAV/CardDAV — одним лёгким Python-процессом без базы данных вовсе. Разберём, сколько памяти он реально ест, от чего зависит аппетит и как не переплатить за тариф под сервис, который сам по себе весит десятки мегабайт.

Что такое Radicale и почему он такой лёгкий

Radicale — это сервер CalDAV (календари) и CardDAV (контакты), написанный на Python, который сознательно избегает всего, что обычно тянет за собой подобный софт. Никакой СУБД: данные хранятся прямо в файловой системе — каждый календарь и каждая адресная книга это папка с файлами .ics/.vcf в формате iCalendar/vCard, человекочитаемым и легко бэкапящимся обычным rsync или tar. Никакого отдельного демона очередей, кеша или воркер-пула — один процесс, который слушает HTTP(S) и отвечает на CalDAV/CardDAV-запросы клиентов (Thunderbird, DAVx5 на Android, встроенные календарь и контакты в iOS/macOS, Evolution).

Архитектурно это ближе к статическому файловому серверу с протокольной обвязкой поверх, чем к полноценному веб-приложению. Именно поэтому Radicale — один из немногих самостоятельных серверов, которые официально рекомендуют запускать даже на Raspberry Pi: разработчики прямо пишут, что процесс укладывается в единицы-десятки мегабайт RAM на скромном железе. Это не рекламный ориентир, а следствие архитектуры: нет ORM, нет пула соединений к БД, нет JIT-прогрева тяжёлого рантайма — интерпретатор CPython плюс небольшой набор чистого Python-кода поверх стандартной библиотеки.

Два режима запуска влияют на итоговую цифру не архитектурой самого Radicale, а тем, что стоит вокруг: встроенный сервер (radicale как самостоятельный процесс) — самый экономный вариант; запуск как WSGI-приложение под uWSGI или Gunicorn добавляет накладные расходы самого WSGI-сервера и, если вы поднимаете несколько воркеров для параллельной обработки запросов, кратно им.

Базовое потребление: встроенный сервер vs WSGI

Минимальная конфигурация — radicale в собственном встроенном режиме (python3 -m radicale), файловое хранилище, авторизация через htpasswd, без TLS-терминации на самом Radicale (её обычно отдают Nginx):

Цифры ориентировочные — точное число зависит от версии Python, версии самого Radicale, количества загруженных модулей аутентификации/прав доступа и от того, сколько запросов клиенты успели сделать с момента старта (Python-процессы обычно чуть «раздуваются» после прогрева за счёт кеша интерпретатора байткода и внутренних структур — это нормально и не течёт бесконтрольно). Порядок величины устойчив: десятки мегабайт, а не сотни. Проверяйте фактику на своём сервере командами из раздела ниже, а не полагайтесь на таблицу как на жёсткий потолок.

Важный нюанс: если вы ставите Radicale через системный пакетный менеджер (apt install radicale на Debian/Ubuntu) — это отдельный процесс. Если через pip install radicale[...] в виртуальном окружении — тоже отдельный процесс, но с собственной копией зависимостей в venv на диске (это про место на диске, не про RAM в рантайме — сама память не удваивается только от наличия venv).

От чего зависит рост потребления памяти

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

• Число одновременных клиентских соединений. Каждое активное HTTP-соединение (например, DAVx5 на телефоне, который держит длинный poll-запрос для быстрой синхронизации) занимает память под буферы соединения. На практике для 5–20 клиентов это единицы мегабайт сверху к базовой цифре.
• Число воркеров WSGI-сервера. Если вы поднимаете uWSGI с processes = 4 для отказоустойчивости или параллельной обработки — это буквально 4 отдельных процесса Python, каждый с собственной базовой памятью интерпретатора. Для домашнего или командного использования 1–2 воркера более чем достаточно, Radicale и один процесс не насыщает при разумной нагрузке.
• Общий размер данных в файлах почти не влияет на RAM в состоянии простоя — Radicale не держит все .ics/.vcf файлы в памяти постоянно, читает их с диска по запросу. Тысячи событий в календаре на итоговый idle-потребление влияют минимально, в отличие от систем с БД, которая кеширует данные в буферном пуле.
• Плагины и кастомные rights/auth-бэкенды. Если вы подключаете внешний плагин авторизации (например, через LDAP) вместо встроенного htpasswd, добавляется вес самого клиента к внешней системе — обычно тоже единицы мегабайт, но не ноль.

Сколько RAM нужно под разные сценарии

Ориентир для планирования тарифа. Radicale почти никогда не будет единственным сервисом на сервере — рядом обычно стоит Nginx как TLS-терминатор и reverse-proxy:

Даже верхняя строка таблицы — скромные цифры по меркам современного VPS. Radicale — один из тех редких сервисов, для которого самый дешёвый тариф с 512 МБ – 1 ГБ RAM оказывается не компромиссом, а комфортным запасом, если на том же сервере не крутится ничего тяжёлого. Если сервер уже занят другими задачами и вы прикидываете общий бюджет памяти под разные сценарии использования, смотрите статью сколько ресурсов нужно VPS для самозанятого и фрилансера — Radicale туда впишется практически без следа в бюджете.

Файловое хранилище: плюсы для памяти и что учесть для дисков

Отсутствие СУБД — главная причина низкого потребления RAM, но у этого решения есть обратная сторона, которую стоит понимать заранее:

• Плюс для памяти. Нет буферного пула, нет кеша запросов, нет процесса СУБД, который в простое всё равно держит выделенный shared_buffers/innodb_buffer_pool_size. Вся память Radicale — это память самого Python-процесса плюс ОС-уровневый дисковый кеш страниц (page cache), который ядро Linux использует прозрачно и который не отнимает память у других процессов — эта часть управляется ядром автоматически и высвобождается по требованию.
• Учитывайте для дисков. Много мелких файлов (.ics на каждое событие в некоторых конфигурациях, .vcf на каждый контакт) создают нагрузку на файловую систему при массовой синхронизации — например, при первом импорте большой адресной книги на несколько тысяч контактов. На SSD/NVMe современных VPS это не проблема, но если вы переносите данные с медленного сетевого диска, первая полная синхронизация может занять заметно больше времени, чем ожидаете.
• Бэкапы становятся тривиальными. Весь стейт Radicale — это одна директория. rsync -a /var/lib/radicale/collections/ backup/ или обычный tar без остановки сервиса (Radicale пишет файлы атомарно) — и у вас полный снапшот всех календарей и контактов. Никакого mysqldump, никакой консистентности транзакций между таблицами — то, что есть на диске, то и есть весь сервис.

Установка и лимиты памяти в конфигурации

Быстрый вариант через systemd (без Docker) — Radicale ставится как системный пакет или через pip, конфигурация лежит в /etc/radicale/config:

[server]
hosts = 127.0.0.1:5232

[auth]
type = htpasswd
htpasswd_filename = /etc/radicale/users
htpasswd_encryption = bcrypt

[storage]
filesystem_folder = /var/lib/radicale/collections

[logging]
level = info

Для systemd-юнита ограничение памяти задаётся напрямую в unit-файле, без Docker:

[Service]
ExecStart=/usr/bin/radicale --config /etc/radicale/config
User=radicale
Group=radicale
MemoryMax=256M
MemoryHigh=192M
Restart=on-failure

[Install]
WantedBy=multi-user.target

MemoryHigh — мягкий порог: systemd начинает throttlить процесс при приближении к нему, но не убивает сразу. MemoryMax — жёсткий потолок, при превышении cgroup убивает процесс через OOM внутри группы. Для Radicale с его скромным аппетитом 256 МБ — комфортный потолок даже с запасом на несколько десятков активных клиентов.

Если предпочитаете Docker — официальный образ поддерживает те же переменные конфигурации через volume с конфиг-файлом:

services:
  radicale:
    image: tomsquest/docker-radicale:latest
    container_name: radicale
    restart: unless-stopped
    mem_limit: 256m
    mem_reservation: 64m
    volumes:
      - ./config:/config
      - ./data:/data
    ports:
      - "127.0.0.1:5232:5232"

В обоих случаях перед Radicale стоит поставить Nginx как TLS-терминатор — сам Radicale лучше не выставлять напрямую в интернет без HTTPS, а базовая настройка reverse-proxy разобрана в статье про Nginx как reverse-proxy на VPS. Сертификат для домена проще всего получить через Let's Encrypt.

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

Таблицы выше — ориентир для старта, а не замена измерению под вашу конкретную нагрузку и число клиентов:

# Если Radicale запущен как systemd-сервис
systemctl status radicale
cat /sys/fs/cgroup/system.slice/radicale.service/memory.current
cat /sys/fs/cgroup/system.slice/radicale.service/memory.peak

# Если через Docker
docker stats --no-stream radicale
docker exec radicale cat /sys/fs/cgroup/memory.peak

# Найти процесс и посмотреть RSS напрямую
ps aux | grep radicale

# Свободная память и swap на хосте целиком
free -h

# Проверка на OOM-килл, если процесс падал без явной причины
dmesg | grep -i "out of memory"
journalctl -u radicale | grep -i oom

Если видите OOMKilled или падения без явной причины в логах — это почти всегда означает не нехватку памяти под сам Radicale, а слишком тесный MemoryMax/mem_limit, выставленный «на всякий случай» для сервиса, который в принципе весит десятки мегабайт. Поднимайте лимит шагами по 64 МБ и смотрите на реальный RSS через ps aux. Общий подход к диагностике нехватки памяти на VPS, если проблема шире одного сервиса, разобран в статье что делать при нехватке RAM.

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