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

MAATRIX

На вопрос «сколько RAM нужно для Nextcloud» отвечают и «512 МБ за глаза», и «меньше 8 ГБ не начинайте» — обе цифры честные, просто про разные установки. Расход памяти задаёт не объём хранилища, а число одновременных запросов и список включённых приложений: машина с 4 ГБ спокойно раздаёт 2 ТБ файлов и падает от одного включённого антивируса. Ниже — разбор по компонентам, команды замера на живой системе и рабочий конфиг под 2 ГБ.

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

Цифры для связки nginx 1.28 + PHP 8.3-FPM + MariaDB 11.8 + Redis на Ubuntu 24.04, где кроме облака на сервере ничего нет. Nextcloud 31 и 32 по памяти ведут себя одинаково.

Строчку вниз сдвигают не пользователи, а приложения: разница между 4 и 16 ГБ — это Collabora, ClamAV и поиск, а не число заведённых аккаунтов. Одновременно активны обычно 10–20 % людей, вот их и считайте. Диска берите объём файлов плюс 20–30 % на превью, версии и корзину.

Почему «512 МБ» из документации — не про ваш сервер

Nextcloud держит в требованиях планку «минимум 512 МБ RAM», и это правда — про сам PHP-код. Но в соседнем разделе тот же проект требует другого: memory_limit у PHP не меньше 512 МБ на один запрос, иначе в админке загорается предупреждение.

The PHP memory limit is below the recommended value of 512MB.

Две цифры совпали случайно. memory_limit — потолок одного воркера, а не резерв: память заранее он не занимает, он убивает скрипт, перешагнувший планку. Поставите 128M — получите не экономию, а вот это в nextcloud.log и белый экран у пользователя:

{"reqId":"kQ3fW1pR","level":3,"app":"PHP","message":"Allowed memory size of
134217728 bytes exhausted (tried to allocate 20480 bytes) at
/var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php#472"}

Обратная крайность опаснее. Восемь воркеров по 512 МБ — это 4 ГБ теоретического спроса на сервере с двумя. До потолка Nextcloud доходит редко, но регулярно: превью через Imagick, сборка zip-архива папки, команды occ. Одного такого запроса хватает, чтобы ядро выбрало жертву:

php-fpm8.3 invoked oom-killer: gfp_mask=0x140cca, order=0, oom_score_adj=0
Out of memory: Killed process 1183 (mariadbd) total-vm:2418772kB,
anon-rss:412984kB, file-rss:0kB, shmem-rss:0kB, UID:111 oom_score_adj:0

Убивают обычно не виновника, а самый жирный процесс — базу. Отсюда классическая жалоба «облако само отваливается раз в неделю»: в логе Nextcloud чисто, всё видно только в dmesg -T | tail -30.

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

Разложим на слагаемые 4-гигабайтную машину с четырнадцатью пользователями и 180 ГБ файлов. Цифры — покой и типичный пик, RSS.

Две вещи, из-за которых арифметика по ps врёт. Первая: OPcache и APCu — разделяемые сегменты. При opcache.memory_consumption=128 и apc.shm_size=128M каждый воркер показывает эти 256 МБ в своём RSS, и восемь воркеров «съедают» два несуществующих гигабайта. Вторая: free -m в колонке free покажет почти ноль на здоровой машине — Linux отдал память под дисковый кеш. Смотрите available:

               total        used        free      shared  buff/cache   available
Mem:            3921        1487         196         214        2452        2103
Swap:           2047          38        2009

Занято 1,5 ГБ, свободно 196 МБ, а доступно реально 2,1 ГБ. Тревожно, когда available уходит ниже 15 % от total, а Swap used растёт день ото дня.

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

PSS вместо RSS. Пакет smem из репозитория Ubuntu делит разделяемую память честно:

sudo apt install -y smem
sudo smem -t -k -P 'php-fpm|mariadbd|redis|nginx' -c 'name pss rss'

Сумма по PSS на той же машине — около 690 МБ против 1010 МБ по RSS: разница как раз в OPcache и APCu.

Пик, а не текущее значение. Тариф считают по худшему моменту, и ядро в Ubuntu 24.04 (cgroup v2) хранит пик по каждому сервису:

systemctl show -p MemoryCurrent --value php8.3-fpm
cat /sys/fs/cgroup/system.slice/php8.3-fpm.service/memory.peak

Разрыв в два-три раза между текущим и пиковым — норма, запас считайте под вторую цифру.

Кто именно съел память. Включите в пуле pm.status_path = /status, отдайте его локально через nginx и смотрите поле last request memory:

curl -s 'http://127.0.0.1/status?full' | grep -B6 'last request memory'

request URI:          /index.php/core/preview?fileId=88213&x=1024&y=1024&a=1
last request memory:  270532608

258 МБ на одну картинку — а рядом обычный PROPFIND синхронизации с last request memory: 33554432, то есть 32 МБ. Разница в восемь раз и есть ответ на вопрос, что закладывать в pm.max_children.

Отдельная засада: occ работает под CLI-версией PHP, а в Debian и Ubuntu /etc/php/8.3/cli/php.ini идёт с memory_limit = -1. Значит, sudo -u www-data php occ files:scan --all в лимит PHP не упрётся — он съест всё и завершится однословным Killed.

Приложения, которые удваивают сервер

Здесь и живёт разница между 2 и 16 ГБ.

Снизьте preview_max_x и preview_max_y с 4096 до 2048 — четырёхкратная экономия, а разницы на экране вы не увидите. Ещё лучше вынести превью из PHP в контейнер Imaginary (около 150 МБ на процесс на Go): 'preview_imaginary_url' => 'http://127.0.0.1:9000' плюс OC\Preview\Imaginary в enabledPreviewProviders.

Что включено сейчас, покажет sudo -u www-data php occ app:list, отключение — occ app:disable <имя>; освободившиеся полтора гигабайта дешевле апгрейда тарифа. Отдельно про All-in-One: образ AIO поднимает 8–12 контейнеров и с Collabora, ClamAV, Imaginary и поиском честно требует 8 ГБ.

Рабочий конфиг под 2 ГБ

Расклад для 3–5 человек. Логика: 2048 МБ минус 450 (MariaDB) минус 30 (Redis) минус 250 (система и nginx) — остаётся около 1300 МБ на PHP. Делим на средний пик воркера в 150 МБ, округляем вниз — восемь.

; /etc/php/8.3/fpm/pool.d/nextcloud.conf
pm = ondemand
pm.max_children = 8
pm.process_idle_timeout = 20s
pm.max_requests = 500
php_admin_value[memory_limit] = 512M

ondemand вместо dynamic — ключевая правка: воркеры поднимаются под запрос и умирают через 20 секунд простоя, ночью пул занимает почти ноль. Плата честная: первый запрос после паузы медленнее на десятки миллисекунд. pm.max_requests = 500 лечит медленное распухание процессов.

База — консервативно, но не в ноль:

[mysqld]
innodb_buffer_pool_size = 256M
innodb_log_file_size    = 64M
max_connections         = 40
transaction_isolation   = READ-COMMITTED
performance_schema      = OFF

READ-COMMITTED рекомендует сама документация Nextcloud. performance_schema в MariaDB и так выключен, а в MySQL 8 включён и стоит 200–400 МБ — если у вас MySQL, это первая строка для правки; подробности в разборе про оптимизацию MySQL под 1 ГБ RAM.

Redis ограничьте, но осторожно:

maxmemory 128mb
maxmemory-policy noeviction
unixsocket /run/redis/redis-server.sock

Именно noeviction. Nextcloud держит в Redis блокировки файлов, и политика allkeys-lru рано или поздно выбросит живой лок — пользователи получат «file is locked» на ровном месте.

Ещё три вещи, которые окупаются на малой памяти:

• Swap на 2 ГБ. В образах VPS его часто нет — проверьте swapon --show, дальше fallocate -l 2G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile, строка в /etc/fstab и vm.swappiness=10. Это подушка на пик, а не замена памяти.
• earlyoom. apt install earlyoom, затем в /etc/default/earlyoom — --prefer '(^|/)php-fpm8.3Частые вопросы
  Хватит ли 1 ГБ RAM для Nextcloud?

  Для одного-двух человек да: pm = ondemand с тремя воркерами, innodb_buffer_pool_size = 128M, превью выключены, swap на 2 ГБ. Первое полное сканирование файлов или обновление из веб-интерфейса на такой машине — рулетка, в dmesg вы увидите Killed process (mariadbd).

  Влияет ли объём хранилища на требования по памяти?

  Почти нет. В RAM живут метаданные из таблицы oc_filecache — порядка 200–400 байт на файл в буферном пуле, то есть сотни мегабайт на миллион файлов. Сервер с 4 ГБ спокойно раздаёт несколько терабайт; расти будет диск, а не память.

  Почему сервер падает ночью, когда никто не работает?

  Ночью сходятся тяжёлые фоновые задачи: cron.php, генерация превью, files:scan, бэкап и mysqldump разом. Разведите их по времени в crontab: CLI-версия PHP идёт с memory_limit = -1 и сама себя не остановит.

  Читайте также

  • Uptime Kuma не шлёт уведомления: причины и решение
  • Uptime Kuma: мониторинг сайта и сервера — настройка
  • Uptime Kuma против Zabbix: что выгоднее и когда

  Нужны сами нейросети для контента?

  Генерируйте изображения, видео и озвучку нейросетями на falapi.io — десятки моделей в одном окне. Оплата картой РФ и по СБП.

  Изображения и ВидеоАудио и звукИИ MAAT — Собеседник