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

MAATRIX

LimeSurvey — не блог и не магазин, и его аппетит к памяти считается по другим правилам. Сама анкета лёгкая: страница с вопросами рендерится быстро и почти не грузит PHP. Память съедают две другие вещи — ветвящаяся логика (relevance-условия, пересчитываемые на каждом шаге) и статистика с экспортом результатов, где движок собирает весь массив ответов разом. Разберём, из чего складывается расход, как его измерить и какие цифры закладывать под опрос на 20 вопросов и под анкету на 300 с ветвлением.

Короткий ответ: сколько RAM закладывать

Ориентиры для nginx 1.28 + PHP-FPM 8.3 + MariaDB 11.4 на Ubuntu 24.04, LimeSurvey 6.x. Официальный минимум разработчиков — 2 ГБ RAM и PHP memory_limit от 128 МБ, но это цифра для установки, а не для рабочей нагрузки с респондентами и экспортом.

Главный вывод из таблицы: прохождение анкеты почти никогда не требует много памяти — тяжело не респондентам, а администратору, когда он открывает статистику или жмёт «Экспорт результатов» на опросе с тысячами ответов.

Из чего складывается память LimeSurvey

LimeSurvey написан на Yii2 — фреймворк тяжелее плоского PHP-скрипта: инициализация MVC, роутинг и ORM для десятков таблиц (lime_survey_*, lime_questions, lime_answers, lime_tokens_*) добавляют накладные расходы ещё до логики самого опроса.

Ключевая разница с обычным сайтом на PHP: у LimeSurvey нет «типового» воркера — RSS процесса, отдающего анкету, и процесса, генерирующего статистику по ней же, различаются на порядок.

Ветвящаяся логика и ExpressionManager — где прячется нагрузка

Relevance-условия («показать вопрос 15, если в вопросе 3 выбран вариант B») обрабатывает ExpressionManager: он парсит уравнения и пересчитывает их при каждом переходе между группами вопросов. На простой анкете это незаметно. На опросе с сотнями вопросов и перекрёстными условиями (вопрос зависит от трёх других, те — ещё от пяти) ExpressionManager держит в памяти дерево зависимостей на весь опрос сразу, а не только на текущую страницу.

Отсюда практическое следствие: два опроса с одинаковым числом вопросов, но разной сложностью логики, требуют разной памяти на воркер — цифра «150 вопросов» в описании ничего не говорит о нагрузке сама по себе.

Что снижает нагрузку без переписывания логики: режим «Только один вопрос на странице» вместо «Вся анкета на одной странице» (тогда пересчитывается relevance не всего опроса разом, а только видимой группы); упрощение вложенных условий там, где хватает простого правила «покажи, если ответ = X» вместо трёхэтажной формулы с sum() и count(); отключённый предпросмотр логики в конструкторе на боевом сервере — он нужен на этапе разработки анкеты, а на проде лишь гоняет ExpressionManager вхолостую.

Экспорт результатов и статистика — главный потребитель памяти

Это узкое место, из-за которого сервер, спокойно держащий сбор ответов, падает в момент, когда администратор решает выгрузить результаты. При экспорте в VV (формат, совместимый с SPSS/R) или в Excel LimeSurvey собирает полную таблицу ответов и размечает её по типам вопросов в памяти PHP-процесса, а не потоково постранично.

Ориентировочно (сильно зависит от числа полей на ответ — считайте по своей анкете, это не универсальная константа): опрос на 100 вопросов с подвопросами даёт 200–400 колонок в выгрузке, и 5000 ответов на такой анкете — уже сотни мегабайт промежуточных данных в процессе. При memory_limit = 128M (дефолт многих сборок PHP) экспорт просто падает:

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted
(tried to allocate 20971520 bytes) in ExpressionManager.php on line ...

Та же логика — у статистики с графиками: чем больше закрытых вопросов и респондентов, тем тяжелее построение диаграмм на лету. На больших опросах статистику стоит смотреть отдельным запросом администратора в спокойное время, а не в пик сбора ответов.

Что помогает: отдельный, более высокий memory_limit для CLI и для пула администратора — респондентам столько не нужно; выгрузка результатов частями через фильтр по датам или токенам вместо одного экспорта «все ответы за всё время»; для регулярных больших выгрузок — RemoteControl API LimeSurvey с постраничным экспортом вместо веб-интерфейса. И не запускайте mysqldump одновременно с ручным экспортом результатов — оба тянут память с двух сторон разом; подробности бэкапа базы — в статье про бэкап MySQL на сервере.

Как измерить свой расход, а не гадать по чужим цифрам

free -m на работающем сервере с LimeSurvey и 4 ГБ RAM:

               total   used   free   shared  buff/cache   available
Mem:            3919   1450    280      90      2189        2201

Смотрите на available: буфер и кеш ядро отдаст под нагрузку, «свободно 280 МБ» — не повод паниковать сам по себе.

ps --no-headers -o rss -C php-fpm8.3 | awk '{s+=$1; n++} END {print n" воркеров, средний RSS "int(s/n/1024)" МБ"}'
apt install -y smem && smem -t -k -P php-fpm | tail -3
cat /sys/fs/cgroup/system.slice/php8.3-fpm.service/memory.peak

smem считает PSS — честную долю на воркер с учётом разделяемых страниц OPcache; сырой RSS завышает картину при большом числе воркеров. memory.peak в cgroup — исторический максимум с момента запуска сервиса, а не текущее значение: он подскажет, хватило ли памяти в момент экспорта или статистики, даже если сейчас всё выглядит спокойно.

Проверьте, не убивало ли ядро процессы раньше — это часто списывают на «глюки хостинга», хотя причина в памяти:

dmesg -T | grep -iE "killed process|out of memory"
grep -c "server reached pm.max_children" /var/log/php8.3-fpm.log
journalctl -u php8.3-fpm --since "-7d" | grep "exited on signal 9"

Если строка Out of memory: Killed process ... (php-fpm8.3) совпадает по времени с жалобой «экспорт не работает» — причина найдена, и это не баг LimeSurvey, а нехватка памяти под конкретный опрос. Общие сценарии нехватки памяти на VPS — в статье что делать при нехватке RAM.

Конфигурация PHP-FPM и MySQL под LimeSurvey

Разделяйте пулы PHP-FPM на «фронт» (респонденты проходят опрос) и «админку» (статистика, экспорт, конструктор) — им нужна разная память на воркер, и общий пул с одним лимитом либо душит экспорт, либо резервирует лишнее под лёгкие страницы анкеты.

/etc/php/8.3/fpm/pool.d/limesurvey-front.conf для 4 ГБ, респонденты:

[limesurvey-front]
listen = /run/php/limesurvey-front.sock
pm = dynamic
pm.max_children = 12
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 500
php_admin_value[memory_limit] = 192M

/etc/php/8.3/fpm/pool.d/limesurvey-admin.conf — отдельный пул под статистику и экспорт:

[limesurvey-admin]
listen = /run/php/limesurvey-admin.sock
pm = ondemand
pm.max_children = 3
pm.process_idle_timeout = 30s
php_admin_value[memory_limit] = 768M
php_admin_value[max_execution_time] = 300

pm = ondemand для админского пула оправдан: экспорт запускают редко, и три воркера по 768 МБ не должны висеть в памяти постоянно — ondemand поднимает процесс под запрос и гасит его после простоя. В nginx маршрутизируйте /admin и /index.php/admin/* на сокет limesurvey-admin, остальное — на limesurvey-front.

Настройка MySQL/MariaDB — по размеру таблиц ответов, а не по проценту от RAM:

SELECT ROUND(SUM(data_length+index_length)/1024/1024) mb
FROM information_schema.tables
WHERE table_schema = 'limesurvey' AND table_name LIKE '%responses%';

Дальше — пул InnoDB с запасом на рост таблицы ответов (она копится с каждым респондентом, в отличие от статичных таблиц конструктора вопросов):

[mysqld]
innodb_buffer_pool_size = 512M
innodb_buffer_pool_instances = 1
max_connections = 40
performance_schema = OFF

Общие приёмы тюнинга MySQL под ограниченную память — в статье оптимизация MySQL под 1 ГБ RAM, а базовая установка — в MySQL на VPS.

Какой сервер взять в MAATRIX под LimeSurvey

Ключевой вопрос при выборе тарифа — не «сколько вопросов в анкете», а «кто и как часто открывает статистику и экспорт». Опрос на 300 вопросов без активной ветвящейся логики спокойно живёт на 4 ГБ. Тот же опрос с ежедневным экспортом всех накопленных ответов для аналитиков — уже кандидат на 8 ГБ, иначе экспорт будет падать именно тогда, когда данные особенно нужны.

Минимум: 1–2 vCPU, 2 ГБ RAM, 25 ГБ NVMe. Один опрос среднего размера без сложного ветвления, до нескольких сотен ответов, экспорт — небольшими выгрузками по фильтру, а не «всё сразу». Держите memory_limit фронтового пула на 128–192 МБ и не открывайте статистику в часы пиковой нагрузки.

Комфортный вариант: 2–4 vCPU, 4–8 ГБ RAM, 40–60 ГБ NVMe. Подходит для анкет с ветвящейся логикой, нескольких параллельных опросов и регулярных экспортов результатов без танцев с фильтрами по датам. Отдельный админский пул PHP-FPM с memory_limit = 768M укладывается свободно, буферный пул InnoDB вмещает таблицы ответов растущего опроса.

Локация выбирайте по географии респондентов, а не только по своей: RU — если опрос идёт для аудитории в России и важна скорость загрузки внутри страны, UK — для европейских исследований (плюс данные респондентов из ЕС логичнее держать в юрисдикции с понятными правилами GDPR), US — для американской аудитории. Apache с mod_php вместо связки nginx + PHP-FPM тоже работает с LimeSurvey, конфигурация применима с поправкой на два пула вместо одного.

LimeSurvey есть в каталоге apps.maatrix.io и разворачивается автоматически при заказе сервера на Ubuntu — база, PHP-FPM и панель настроены заранее, доступы приходят в личный кабинет. Оплата картами российских банков, по СБП или криптовалютой — иностранная карта не нужна вне зависимости от локации сервера.

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