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

MAATRIX

DAViCal — один из самых старых CalDAV/CardDAV-серверов, который до сих пор держат в проде из-за предсказуемости: PHP, PostgreSQL, никакой магии. Но именно из-за этой архитектуры вопрос «сколько нужно RAM» звучит иначе, чем для лёгких однопроцессных серверов вроде Radicale. Здесь память съедают три разных компонента одновременно, и если считать «на глаз», сервер либо простаивает переплаченным, либо начинает уходить в своп при первой же волне синхронизаций с телефонов. Разберём по частям, сколько реально нужно и как подогнать конфиг под то, что уже арендовано.

Архитектура DAViCal и почему нагрузка на RAM нетипичная

DAViCal — это не демон в привычном смысле. У него нет своего процесса, который постоянно висит в памяти и ждёт подключений, как у Radicale или Baikal-в-встроенном-режиме. Вместо этого связка выглядит так:

• Apache (или nginx + php-fpm) принимает HTTP-запрос по протоколу CalDAV/CardDAV (это WebDAV-расширение поверх обычного HTTP);
• PHP (mod_php внутри Apache или отдельный php-fpm) выполняет скрипты DAViCal, построенные на библиотеке awl;
• PostgreSQL хранит все календари, контакты, ACL и историю изменений и отвечает на SQL-запросы от PHP-кода.

Каждый запрос на синхронизацию — это короткая цепочка: Apache → PHP → PostgreSQL → PHP → Apache → клиент. Никакого долгоживущего соединения не остаётся, но при этом задействованы сразу три системы со своими требованиями к памяти. Отсюда и путаница в оценках: кто-то меряет «пустой» сервер сразу после установки, кто-то — под нагрузкой с десятками одновременных клиентов, которые синхронизируются раз в 5–15 минут (так по умолчанию настроены DAVx5 на Android, Thunderbird с TbSync, Apple Calendar и большинство CalDAV-клиентов).

Хорошая новость: CalDAV-трафик — это не веб-сайт с постоянными посетителями. Даже 50–100 пользователей редко создают больше 3–5 одновременных запросов в моменте, потому что клиенты синхронизируются не хором, а вразнобой по своему расписанию. Это сильно снижает требования к пиковой параллельности по сравнению, например, с сайтом на WordPress с тем же числом активных людей.

Сколько RAM нужно: ориентиры по сценариям

Ниже — не измеренные бенчмарки, а практический ориентир на основе типовой раскладки памяти по компонентам (см. следующий раздел). У вас может быть на 20–30% больше или меньше в зависимости от версии дистрибутива, набора установленных PHP-модулей и того, крутится ли на той же машине что-то ещё.

Формально DAViCal и PostgreSQL стартуют и на 512 МБ — пакет davical из репозиториев Debian/Ubuntu ставится без проблем. Но 512 МБ — это память под сам процесс синхронизации, без учёта регулярных операций ОС: обновлений пакетов, logrotate, cron-бэкапов pg_dump, SSH-сессий администратора. На практике именно эти фоновые процессы, а не сам DAViCal, чаще всего выталкивают сервер в своп на маленьких тарифах.

Куда уходит память: PostgreSQL, Apache, PHP и ОС

Чтобы не гадать, разложим потребление по слоям для условного сервера с 1–2 ГБ RAM:

• ОС (Debian/Ubuntu minimal) — обычно 150–300 МБ в простое: systemd, sshd, cron, journald, сетевой стек.
• PostgreSQL — базовый процесс-координатор около 10–20 МБ, плюс shared_buffers (общий кэш страниц, выделяется один раз при старте), плюс по 5–10 МБ на каждое активное соединение из пула, плюс work_mem на операции сортировки/группировки в рамках отдельного запроса.
• Apache + mod_php — каждый worker-процесс с загруженным PHP-интерпретатором и его расширениями (pgsql, xml, mbstring, curl и т.д.) занимает ориентировочно 20–40 МБ. Если используете mpm_prefork (стандарт для mod_php), это умножается на число одновременных воркеров.
• DAViCal сам по себе — практически ничего не весит вне выполнения запроса: это набор PHP-скриптов, не резидентный процесс.

Посмотреть текущую картину на своём сервере проще всего так:

free -h
ps aux --sort=-%mem | head -n 15
sudo -u postgres psql -c "SHOW shared_buffers;"

Если видите, что postgres уже держит 300+ МБ, а Apache при этом создал 15 воркеров с mod_php — скорее всего, конфиг не подогнан под объём RAM, а взят по умолчанию из пакета, рассчитанного на «обычный» сервер с 4–8 ГБ. Разберём, как это поправить.

Общую логику установки самого PostgreSQL и создания базы для DAViCal разбирали отдельно — см. установку PostgreSQL на VPS, если ставите с нуля.

Тюнинг PostgreSQL под небольшой сервер

DAViCal не нагружает PostgreSQL сложными аналитическими запросами — это в основном точечные SELECT/INSERT/UPDATE по индексированным полям (uid события, коллекция календаря, пользователь). Это значит, что агрессивный shared_buffers и большой work_mem, которые нужны для аналитики, здесь избыточны.

Для сервера с 1 ГБ RAM в /etc/postgresql/*/main/postgresql.conf:

shared_buffers = 128MB
effective_cache_size = 384MB
work_mem = 4MB
maintenance_work_mem = 32MB
max_connections = 20

Для сервера с 2 ГБ RAM, если DAViCal делит машину с Apache и PHP (а не стоит на отдельной БД-машине):

shared_buffers = 256MB
effective_cache_size = 1GB
work_mem = 8MB
maintenance_work_mem = 64MB
max_connections = 30

max_connections для DAViCal почти никогда не нужно поднимать выше 30–50: сервер не держит постоянные соединения от клиентов, а Apache/PHP используют короткоживущий пул к базе на время обработки запроса. Если планируете держать 100+ активных пользователей на одной машине, посмотрите также общий разбор параметров в статье про тюнинг PostgreSQL на VPS — там подробнее про effective_io_concurrency, checkpoint_completion_target и что зависит от диска, а не от RAM.

После правки конфига:

sudo systemctl restart postgresql
sudo -u postgres psql -c "SHOW shared_buffers;"

Apache и PHP: сокращаем память на воркерах

Стандартная установка DAViCal через apt install davical тянет за собой Apache с mod_php и mpm_prefork — самый прожорливый по памяти вариант, зато самый простой в настройке. Для маленького сервера имеет смысл вручную ограничить число воркеров, а не полагаться на дефолты, рассчитанные на общий веб-хостинг.

Для сервера с 1–2 ГБ RAM в /etc/apache2/mods-available/mpm_prefork.conf:

<IfModule mpm_prefork_module>
    StartServers          2
    MinSpareServers       2
    MaxSpareServers       4
    MaxRequestWorkers     10
    MaxConnectionsPerChild 1000
</IfModule>

При 10 воркерах по ~30 МБ каждый (с учётом PHP и расширений) получаем пиковый расход около 300 МБ на Apache — этого с запасом хватает для команды до 20–30 человек, учитывая, что синхронизации не приходят одновременным потоком.

Если сервер планово держит 50+ пользователей, есть смысл перейти на связку php-fpm + mpm_event: Apache в event-режиме сам по себе легче на статике, а php-fpm управляет пулом PHP-процессов отдельно и умеет их гасить при простое:

sudo apt install php-fpm libapache2-mod-fcgid
sudo a2dismod mpm_prefork php8.3
sudo a2enmod mpm_event proxy_fcgi setenvif
sudo a2enconf php8.3-fpm

В пуле php-fpm (/etc/php/8.3/fpm/pool.d/www.conf) для небольшого сервера стоит выставить pm = ondemand — процессы будут стартовать по запросу и завершаться после периода простоя, а не висеть в памяти постоянно:

pm = ondemand
pm.max_children = 8
pm.process_idle_timeout = 30s

Это заметно снижает базовое потребление в те часы, когда синхронизаций почти нет (например, ночью), ценой небольшой задержки на «холодный старт» первого запроса.

Признаки нехватки памяти и что делать

Три места, где нехватка RAM проявляется быстрее всего:

• PostgreSQL перезапускается или логирует ошибки нехватки памяти — смотрите journalctl -u postgresql и dmesg -T | grep -i "out of memory". Подробный разбор именно этой ситуации — в статье PostgreSQL out of memory: причины и решение.
• Клиенты получают 502/504 при синхронизации — обычно значит, что Apache/php-fpm упёрлись в лимит воркеров и новые запросы встают в очередь дольше таймаута.
• Сервер уходит в активный своп — проверяется через vmstat 1 (колонки si/so растут) или free -h (Swap используется постоянно, а не разово).

Быстрая диагностика:

free -h
vmstat 1 5
sudo dmesg -T | grep -i "out of memory"
sudo journalctl -k -b | grep -i oom

Своп — это страховка на случай кратковременного пика, а не постоянный режим работы: если сервер живёт в свопе часами, RAM реально не хватает и её нужно добавить, а не тюнить конфиги дальше. Как подобрать разумный размер swap-файла для такого сценария — в статье правильный размер swap для VPS.

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

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