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

MAATRIX

Kimai — не самый прожорливый self-hosted сервис, и именно поэтому с ним легко ошибиться в другую сторону: взять сервер «на вырост» с запасом в 8 ГБ, которые никогда не понадобятся, либо наоборот — воткнуть его на минимальный тариф и потом удивляться, почему при отчёте на 40 человек за квартал сервер начинает подтормаживать. Разберём, из чего складывается память для Kimai на практике: сколько ест сам стек (PHP-FPM, MySQL/MariaDB, веб-сервер), как это меняется с ростом команды и что настроить, чтобы не переплачивать за RAM, которая просто простаивает.

Из чего состоит Kimai и что реально ест память

Kimai — это классическое PHP-приложение на Symfony, и по архитектуре он проще, чем большинство self-hosted сервисов, о которых пишут «сколько RAM нужно». Никакой очереди сообщений, никакой отдельной аналитической СУБД, никакого обязательного Redis — в базовой конфигурации это три компонента:

• PHP-FPM — обрабатывает сами запросы: рендерит страницы, считает отчёты, отдаёт API для мобильного приложения и браузерного плагина учёта времени. Основной потребитель памяти под нагрузкой, потому что каждый воркер FPM держит в памяти загруженный Symfony-контейнер.
• MySQL или MariaDB — хранит всё: пользователей, проекты, тайм-записи, теги, инвойсы. При небольшом числе записей база лёгкая, но с ростом истории (годы тайм-трекинга по десяткам проектов) начинает требовать более серьёзный buffer pool для быстрых отчётов.
• Nginx или Apache — веб-сервер перед PHP-FPM, сам по себе почти не заметен по памяти (десятки мегабайт), но именно через него удобнее всего отдавать статику и настраивать TLS.

Опционально в схему добавляется Redis — если включить кеширование сессий или очередь для тяжёлых фоновых задач (массовый экспорт, генерация PDF-инвойсов пачками), но для команд до 30-40 человек это чаще излишество: встроенного файлового или БД-кеша Symfony хватает с запасом.

Ключевая особенность именно для расчёта памяти: Kimai не держит долгоживущее состояние в оперативке между запросами (в отличие, скажем, от очередей задач или брокеров сообщений), поэтому его аппетит к RAM почти линейно зависит от двух вещей — числа одновременных пользователей, дёргающих PHP-FPM, и объёма данных, который MySQL держит в буфере для быстрых ответов.

Соло и маленькая команда: 1-5 пользователей

Для фрилансера, который ведёт учёт времени сам на себя, или маленькой команды до 5 человек Kimai — один из самых нетребовательных self-hosted инструментов из тех, что вообще стоит разворачивать на отдельном VPS, а не на общем тарифе.

Ориентировочная раскладка памяти при таком масштабе (Docker-инсталляция, MariaDB + PHP-FPM + Nginx):

Это ориентир, а не гарантированное число — конкретное потребление зависит от версии PHP, включённых плагинов Kimai и того, сколько исторических записей уже накопилось в базе. Но даже с запасом на систему, SSH и базовый мониторинг сервер на 1-2 ГБ RAM для такого масштаба будет комфортным, а не впритык. Опускаться ниже 1 ГБ не стоит: MySQL плохо переживает ситуации, когда ему совсем нечем дышать, и первый же неудачный запрос с JOIN по большой таблице тайм-записей может привести к OOM-килу процесса.

Если бюджет совсем жёсткий и сервер нужен ещё для чего-то параллельно — почитайте про оптимизацию MySQL под 1 ГБ RAM: большая часть советов оттуда напрямую применима и к Kimai, потому что узкое место у них одинаковое — buffer pool и число одновременных соединений.

Команда 5-20 человек: где начинает ощущаться нагрузка

На этом масштабе Kimai обычно используют не просто для личного учёта времени, а как часть рабочего процесса: тайм-трекинг привязан к проектам, есть тегирование, генерируются отчёты по клиентам и биллингу, кто-то параллельно смотрит дашборд с активными таймерами. Нагрузка перестаёт быть «редкой» и становится постоянной в рабочие часы.

Что меняется по памяти:

• PHP-FPM приходится держать больше воркеров одновременно — условно 5-10 вместо 2-3, потому что запросы от 15-20 человек в рабочее время идут параллельно. Каждый воркер с загруженным приложением занимает от 25 до 60 МБ в зависимости от того, что он обрабатывает: простая страница списка или тяжёлый отчёт с агрегацией.
• MySQL/MariaDB начинает требовать больше буфера, если история растёт — за год активного использования командой из 15-20 человек база вполне может дорасти до заметной доли гигабайта, и buffer pool стоит увеличивать соразмерно.
• Добавляются регулярные фоновые операции — экспорт в PDF/Excel, синхронизация через API, что даёт периодические, но не постоянные всплески нагрузки.

Ориентировочно для 5-20 пользователей закладывайте 2-4 ГБ RAM. Нижняя граница подойдёт, если у команды нет привычки формировать тяжёлые отчёты по всей истории одновременно; верхняя — комфортный запас, если отчётность и биллинг через Kimai используются активно, плюс на сервере крутится что-то ещё (например, обратный прокси для нескольких сервисов).

Агентство 20-50+ человек и мультитенантность

На этом масштабе Kimai чаще всего используют веб-студии и агентства — с несколькими клиентами, десятками активных проектов и биллингом, завязанным на тайм-трекинг напрямую (инвойсы генерируются из отработанных часов). Здесь память уже не «запас на всякий случай», а реальный рабочий ресурс.

Что стоит учитывать:

• Число одновременных PHP-FPM воркеров растёт быстрее линейно, если у команды пиковые часы совпадают (все включают таймер в 9:00 и выключают в 18:00) — под такие всплески нужен запас в pm.max_children, а значит и в памяти под них.
• Тяжёлые отчёты — сводки по всем проектам за квартал, выгрузки для бухгалтерии — на большой истории могут на несколько секунд занимать заметный кусок памяти MySQL под временные таблицы и сортировку, особенно если в запросе нет подходящего индекса.
• Если Kimai используется мультитенантно (несколько независимых команд/клиентов на одной инсталляции через права доступа, а не через отдельные окружения), нагрузка суммируется на одну базу и один пул PHP-FPM — это упрощает администрирование, но требует закладывать память с запасом на пиковую одновременную нагрузку, а не на среднюю.

Для 20-50 активных пользователей разумный диапазон — 4-8 ГБ RAM, 2-4 vCPU. Если команда больше 50 человек или отчётность формируется постоянно (не эпизодически, а как часть ежедневной работы менеджеров), стоит смотреть на выделенный сервер, а не VPS с общими ресурсами — там колебания соседей по хосту меньше влияют на время ответа под пиковой нагрузкой. Похожая логика подбора ресурсов под учёт времени и биллинг разобрана в статье про VPS для самозанятого и фрилансера — пригодится, если Kimai у вас не единственный инструмент такого рода.

Тюнинг MySQL/MariaDB и PHP-FPM под вашу RAM

Дефолтные конфиги MySQL и PHP-FPM в большинстве дистрибутивных пакетов рассчитаны на «средний» сервер и часто либо съедают больше памяти, чем нужно на маленьком VPS, либо наоборот — душат производительность на сервере с запасом. Настройте оба компонента под фактический объём RAM.

Для MariaDB/MySQL ключевой параметр — innodb_buffer_pool_size, он определяет, сколько данных и индексов держится в памяти вместо диска:

# /etc/mysql/mariadb.conf.d/50-server.cnf
[mysqld]
# для VPS с 1-2 ГБ RAM
innodb_buffer_pool_size = 256M
max_connections = 30

# для VPS с 4-8 ГБ RAM
innodb_buffer_pool_size = 1G
max_connections = 80

Общее правило — buffer pool на 50-70% от объёма RAM, выделенного под MySQL (не под весь сервер целиком, с учётом того, что PHP-FPM и веб-сервер тоже забирают свою долю).

Для PHP-FPM важно ограничить число воркеров так, чтобы они физически помещались в память, а не полагаться на дефолт:

; /etc/php/8.3/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 10
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 6

Формула простая: pm.max_children = (память, выделенная под PHP-FPM) / (средний размер одного воркера). Если через docker stats или ps aux --sort=-rss вы видите, что один процесс FPM с приложением Kimai занимает около 40 МБ, а под PHP-FPM выделено 400 МБ — не ставьте max_children больше 8-10, иначе при реальном всплеске запросов сервер уйдёт в своп или потеряет процессы по OOM.

Проверить, кто и сколько ест память на живом сервере, можно без дополнительных утилит:

# суммарная память по системе
free -h

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

# если классическая установка — по процессам
ps aux --sort=-%mem | head -15

Если после тюнинга память всё равно периодически подходит к пределу под пиковой нагрузкой — не полагайтесь на swap как на постоянное решение, а смотрите, что реально настроить: подробнее в статье про правильный размер swap для VPS. Своп спасает от мгновенного OOM-килла, но постоянная работа из свопа на медленном диске сама по себе превращается в проблему производительности для СУБД.

Docker-compose vs классическая установка: что экономнее

Официальный способ развернуть Kimai — Docker-образ, и у него есть накладные расходы по памяти по сравнению с классической установкой пакетами прямо на VPS: сам демон Docker, сетевые прослойки между контейнерами, отдельные процессы для каждого сервиса вместо общего systemd. На маленьких серверах (1-2 ГБ) этот оверхед — не абстракция, а реальные 100-200 МБ, которые могли бы уйти под buffer pool MySQL.

Что выбрать по памяти:

Если сервер небольшой и выделен именно под Kimai (не делит ресурсы с десятком других сервисов), классическая установка даёт немного больше запаса под тот же тариф. Если Kimai — один из нескольких self-hosted сервисов на общем сервере, Docker удобнее с точки зрения изоляции зависимостей, и лишние 150-200 МБ на 4+ ГБ RAM обычно не критичны. Пошаговый разбор установки и тюнинга MySQL под похожие PHP-приложения есть в статье про установку MySQL на VPS — принципы там применимы и к Kimai.

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