Сервер под ERPNext: ресурсы для 10–50 пользователей и что делать, когда не хватает

Для запуска ERPNext в Docker называют минимум 1 ГБ памяти и один процессор, но рабочей системе нужно от 4 ГБ, а на 10–50 пользователей я закладываю 8–16 ГБ и SSD. Это оценка, не замер. Ниже: из чего складывается нагрузка, что тормозит первым и как настроить базу, не покупая новое железо.

Минимальные требования ERPNext и почему «1 ГБ памяти» только для запуска

На форуме сообщества Frappe для запуска ERPNext в Docker называют минимум: 1 ГБ оперативной памяти, 1 ГБ файла подкачки и один процессор. Официальная документация отдельной цифры по памяти не даёт. Это порог, при котором контейнеры поднимаются и открывается страница входа, но не конфигурация для работы. На такой машине один пользователь с тяжёлым отчётом заберёт всю память, а фоновые задачи начнут вытеснять друг друга. Для рабочей системы с базой данных, Redis и воркерами закладывают не меньше 4 ГБ, и это нижняя граница, а не комфортный размер.

Программные требования зависят от версии, и это важно, потому что их часто путают. По странице установки Frappe на 1 октября 2026 года для веток v14 и v15 нужны MariaDB 10.6.6 или новее, Python 3.10 и новее, Node.js 18 и новее, Redis или Valkey шестой версии, Yarn 1.12 и новее. Для v16 и develop указаны MariaDB 11.8, Python 3.14, Node.js 24, Redis или Valkey 6 и новее. Также нужен wkhtmltopdf версии 0.12.6 с патченым Qt для печатных форм и cron для задач. В Docker всё это упаковано в образы, но знать требования полезно, если вы собираете свой образ с доработками. Если вы решили ставить систему на собственный сервер и ищете подрядчика, посмотрите, как мы подходим к таким проектам на странице услуги внедрение open-source.

Операционная система: документация говорит, что подходит любой дистрибутив Linux и macOS, а пользователям Windows предлагает Ubuntu внутри WSL. Запускать боевую систему на Windows не стоит: на форуме сообщества WSL не рекомендуют для production, а для боевых контейнеров Linux остаётся основной платформой. Диск: SSD обязателен, потому что база и фоновые пересчёты упираются именно в ожидание диска, а не в процессор. Подробнее про влияние носителей на производительность у нас есть материал про SSD и RAID в серверах.

Сводка для первого приближения. | Режим | Память | Процессор | Диск | Комментарий | |---|---|---|---|---| | Только запуск, проба | 1 ГБ + 1 ГБ swap | 1 ядро | любой | не для работы | | Рабочий минимум | 4 ГБ | 2 ядра | SSD | единицы пользователей, без тяжёлых отчётов | | Команда 5 человек | 4–8 ГБ | 2–4 ядра | SSD | ориентир ITfresh, нужен тест нагрузки |

Из чего складывается нагрузка: backend, MariaDB, Redis и фоновые воркеры

ERPNext — это не один процесс, а набор. Веб-часть (Python и Gunicorn) обслуживает запросы пользователей. MariaDB хранит данные и выполняет запросы. Redis работает в нескольких ролях: кэш, очередь задач и обмен сообщениями для интерфейса реального времени. Фоновые воркеры выполняют тяжёлые операции, и их делят на короткие очереди (отправка писем) и длинные (отчёты, импорт). Планировщик запускает регулярные задачи. Когда говорят «ERPNext требует памяти», имеют в виду сумму всех этих потребителей.

Кто сколько потребляет, определить нельзя, не замерив. Но направление понятно. База данных — самый прожорливый потребитель: чем больше памяти под её буфер, тем реже она ходит на диск. Redis для кэша ограничен собственным лимитом: по документации Frappe в конфигурации кэша максимальный объём по умолчанию составляет 737 МБ, а при его достижении вытесняются давно не использованные ключи (политика allkeys-lru). Python-процессы растут с числом одновременных запросов и размером обрабатываемых документов.

Что видно в работающей системе. Команда docker stats --no-stream покажет, кто занимает память и процессор в данный момент, free -h покажет общую картину, а в логах MariaDB появляются предупреждения о блокировках. Эти три источника — первая точка, с которой я начинаю разговор о производительности.

# что потребляет контейнеры, один снимок
docker stats --no-stream

# общая память и swap
free -h

Ещё одна важная деталь: нагрузка неравномерна. Утром в понедельник пять человек одновременно открывают списки и отчёты. В конце месяца бухгалтерия запускает тяжёлые отчёты за период. Ночью идут резервные копии, а команда резервирования на большой базе может загрузить до трёх ядер. Ресурсы подбирают под пик, а не под среднее, и расписание резервного копирования и пересчётов переносят на ночь.

Ориентиры на 10, 30 и 50 пользователей: оценка, а не бенчмарк

Точных замеров по числу пользователей в нашей базе знаний нет, и в публичной документации Frappe их тоже нет: результат зависит от отчётов, объёма склада и интеграций. Поэтому ниже оценки на основе того, как мы разворачиваем небольшие установки и что видим в эксплуатации. Для пяти пользователей ITfresh берёт VPS с запасом, 4–8 ГБ памяти. На десять-двадцать человек я стартую с 8 ГБ памяти, четырёх виртуальных ядер и SSD. На тридцать-пятьдесят человек стартую с 16 ГБ, шести-восьми ядер и SSD с запасом. После запуска смотрим мониторинг и корректируем. | Пользователей | Память | Ядра | Диск | Статус цифр | |---|---|---|---|---| | до 5 | 4–8 ГБ | 2–4 | SSD | ориентир ITfresh | | 10–20 | 8 ГБ | 4 | SSD | оценка, подтверждать замером | | 30–50 | 16 ГБ | 6–8 | SSD с запасом | оценка, подтверждать замером |

Почему «пользователей» недостаточно. Двадцать человек, которые открывают заявки и согласуют, нагружают систему меньше, чем пять, которые каждый час строят отчёты по складу за год. Поэтому вместе с числом пользователей я спрашиваю: сколько складских документов в день, есть ли партионный и серийный учёт, как часто запускаются тяжёлые отчёты, есть ли интеграции, которые вставляют документы потоком. Эти ответы влияют на размер сервера сильнее, чем цифра в штатном расписании.

Что мерить, чтобы подтвердить оценку. Занятую память и использование swap: постоянный swap — признак нехватки. Среднюю нагрузку процессора (load) в сравнении с числом ядер. Ожидание диска. Время выполнения запросов базы. Длину очередей фоновых задач. Если очередь задач растёт и не рассасывается, воркеры не успевают, и проблема не обязательно в памяти. Эти пять показателей достаточно регулярно записывать в систему мониторинга: как поставить такой контур, мы разбирали в материале про стек мониторинга на Linux, а для настройки под ключ есть мониторинг Zabbix.

Одно предупреждение про виртуальные серверы. «Четыре ядра» у разных хостеров дают разную производительность, а «SSD» бывает сетевым диском с высокой задержкой. Прежде чем выбрать тариф, запустите тест диска и смотрите на задержку, а не только на объём. Для сравнения вариантов размещения (арендовать сервер, купить, взять облако) полезны материалы про аренду и покупку сервера и про масштабирование серверов по числу пользователей: методика расчёта там другая, но логика запаса та же.

Что тормозит первым: тяжёлые отчёты, пересчёт склада и большие заявки

По моему опыту и по описаниям в нашей базе знаний, ERPNext тормозит в трёх местах, и ни одно из них не лечится «добавим памяти» в первую очередь. Первое: тяжёлые отчёты вроде баланса склада и главной книги за год. Они грузят базу и могут блокировать транзакции других пользователей, а пользователь видит «Request Timed Out». Второе: пересчёт стоимости склада. Когда проводятся документы задним числом, система создаёт задание пересчёта (Repost Item Valuation), а параллельное проведение складских документов иногда заканчивается взаимной блокировкой в таблице движений. Третье: большие документы. На форуме сообщества описаны случаи, когда в версии 15 создание заказа поставщику из заявки на полторы сотни строк подвисало на несколько секунд; на своих объёмах это стоит проверить.

Дерево «симптом, причина, действие» выглядит так. | Симптом | Вероятная причина | Что делать | |---|---|---| | Request Timed Out на отчёте за год | тяжёлый запрос к базе | запускать вне пика, сузить период, фильтры по складу | | Lock Wait Timeout или Deadlock при проведении | параллельное проведение и пересчёт регистра | ограничить время пересчёта внепиковыми часами | | Зависание создания заказа из большой заявки | множественные запросы интерфейса в версии 15 | разбить заявку, проверить на своих объёмах | | Рост базы без роста данных | лог-таблицы Error Log и глобальный поиск | регулярная очистка |

Про пересчёт склада подробнее, потому что это самая частая причина «по утрам тормозит». В Stock Reposting Settings есть опция «Limit timeslot for Stock Reposting»: она ограничивает время пересчёта заданными часами и помогает избежать взаимных блокировок, а документация советует не проводить документы задним числом более чем на месяц, так как пересчёт долгих периодов упирается в таймаут. Для ошибок есть отчёт Stock Ledger Variance, который находит расхождения и позволяет создать записи пересчёта одной кнопкой. Делайте это вне рабочего времени.

Массовая синхронизация через REST. Если вы подключаете внешнюю систему, которая вставляет документы потоком в несколько параллельных запросов, получите ошибки таймаута блокировки (Lock Wait Timeout Exceeded). Не обходите это добавлением процессоров: уменьшите параллелизм, ставьте вставку в очередь и не пишите в базу напрямую SQL-запросами в обход системы, это ломает проверки и целостность.

Как настроить MariaDB и Redis до покупки нового железа

Самая дешёвая настройка с самым заметным эффектом — размер буфера InnoDB. Параметр innodb_buffer_pool_size задаёт, сколько памяти база отводит под кэш таблиц и индексов. По документации MariaDB, значение по умолчанию составляет 128 МиБ, и это главный параметр для сервера, где преобладают таблицы InnoDB. Для сервера, предназначенного только под базу, документация допускает до 80 процентов памяти. Но у нас на одной машине живут и приложение, и Redis, и воркеры, поэтому доля намного скромнее, и её подбирают по замерам.

# /etc/mysql/my.cnf (пример для общей машины с 16 ГБ, подбирать по замерам)
[mysqld]
innodb_buffer_pool_size = 6G

Значение в примере иллюстративное. Начните с трети-половины памяти машины и смотрите на метрики. По документации MariaDB параметр динамический, то есть его можно менять без перезапуска, но после изменения проверьте фактическое значение через SHOW VARIABLES на своей сборке.

Как понять, что буфера не хватает. Сравните число чтений с диска и общее число запросов на чтение в статусе базы.

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';

Если доля чтений с диска (Innodb_buffer_pool_reads) заметна на фоне общего числа запросов (Innodb_buffer_pool_read_requests), буфер мал или база выросла. Это не приговор, а повод увеличить буфер или разобраться, какие запросы читают слишком много.

Redis. Для кэша Frappe конфигурация лежит в файле redis_cache.conf, главный параметр там maxmemory (по умолчанию 737 МБ), политика вытеснения allkeys-lru, а запись на диск отключена: кэш не обязан переживать перезапуск. Документация Frappe не советует менять там что-либо кроме объёма памяти. Для Redis очереди политика иная: терять задачи нельзя, поэтому её не трогаем. Чаще всего правки Redis сводятся к одному: убедиться, что на машине хватает памяти под лимит кэша.

Очистка. Лог-таблицы (журнал ошибок, глобальный поиск) разрастаются, и их нужно периодически чистить: в ERPNext для этого есть настройки автоматической очистки журналов, проверьте их в своей версии. Резервные копии на большой базе грузят процессор, поэтому команду bench --site site1.example.com backup ставят в ночное расписание. Размер хранилища под копии считайте как несколько полных копий базы и файлов: чем короче хранение, тем больше риск остаться без нужной версии.

Когда выносить базу на отдельный сервер и нужна ли реплика

Для небольших компаний отдельный сервер базы данных почти никогда не нужен. Один хорошо настроенный сервер на 16 ГБ переносит нагрузку тридцати-пятидесяти человек, если нет нетипичных интеграций и отчётов. Выносить базу имеет смысл, когда замеры показывают, что процессорное время приложения и базы конкурируют, и настройка буфера и расписания уже не помогает. Тогда база получает свою машину с большим объёмом памяти и быстрым диском, а приложение и воркеры остаются отдельно.

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

Лестница роста, которую я предлагаю клиентам. Ступень первая: настроить буфер базы, ограничить Redis, чистить логи. Ступень вторая: добавить память и ядра на той же машине. Ступень третья: вынести базу на отдельный сервер. Ступень четвёртая: реплика для тяжёлых отчётов. На каждой ступени я прошу замерить показатели до и после, иначе непонятно, помогло ли действие. Переходить на следующую ступень стоит, только когда предыдущая исчерпана.

Отдельно скажу про отказоустойчивость. Даже один сервер можно сделать надёжнее без сложных схем: регулярные резервные копии на другое хранилище и проверенное восстановление. Горячий резерв из двух серверов с репликацией базы возможен, но его сопровождение дороже самой системы для небольшой компании. Я чаще предлагаю простую схему: ночная копия на внешнее хранилище и план восстановления с известным временем.

Как «Газон Центр» на 40 рабочих мест подбирала сервер

Условный пример: компания по благоустройству «Газон Центр», сорок рабочих мест, из них около двадцати активных одновременно. Все цифры придуманы для иллюстрации. Работа идёт по заказам и объектам, склад небольшой, есть закупки и проекты. Тяжёлых производственных расчётов нет, но бухгалтерия раз в месяц строит большие отчёты. Исходный вопрос: «хватит ли виртуального сервера на 8 ГБ?».

Что мы сделали. Сначала собрали вводные: число документов в день, наличие партионного учёта, расписание отчётов, интеграции. Затем выбрали стартовую конфигурацию из таблицы выше для тридцати-пятидесяти пользователей: 16 ГБ памяти, 8 ядер, SSD. Настроили буфер базы, лимит кэша Redis и ночное расписание копий и пересчётов. Включили мониторинг памяти, нагрузки, ожидания диска и очередей.

Что показал первый месяц в этом примере. Пиковая нагрузка приходилась на утренние часы понедельника и на конец месяца. Пересчёт склада на день закрытия периода удалось сдвинуть на ночь. Одна тяжёлая отчётность за год блокировала других, и её перенесли на вечер. Размер сервера оказался достаточным, и нового железа не понадобилось. Если бы метрики показали постоянный swap и растущую очередь, следующей ступенью было бы увеличение памяти.

Урок для вашей установки: не покупайте железо «с запасом на всякий случай», сначала запустите систему на разумной конфигурации и измеряйте. Облачный хостинг позволяет менять размер сервера за минуты, а купленный сервер нельзя быстро уменьшить. Для расчётов по затратам на собственный сервер и облако полезен наш разбор облако или собственный сервер: он написан про 1С, но формула затрат та же.

Хороший размер сервера теряет смысл через полгода, если за системой никто не следит. Что я закладываю в регламент. Мониторинг памяти, нагрузки, диска и очередей с оповещением, а не просто график. Проверка свободного места на разделе с базой и резервными копиями. Плановое обновление версий в тестовой копии до боевого сайта: версии Frappe и ERPNext должны совпадать, а откатить версию базы нельзя, возможен только накат патчей или восстановление из копии.

Второе: доработки. Если кто-то правит базовые типы документов напрямую, обновления начинают ломаться, и придётся тратить ресурсы на «починку» вместо роста. Доработки оформляются отдельным приложением и хранятся в репозитории. Это относится не только к удобству, но и к размеру сервера: неоптимальный код доработки может создавать нагрузку, которую никакая память не скроет.

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

И последнее: границы моего знания. Бенчмарков под вашу нагрузку у меня нет, цифры в таблицах — стартовые оценки, и вы их подтверждаете замером. Особенности версии 16, включая требования к MariaDB, я привожу по странице установки Frappe, а сопоставимые версии MariaDB в compose-файлах проекта могут отличаться: сверяйтесь с файлами той версии, которую ставите.

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