Как понять, что серверу не хватает оперативной памяти?

Question

Иногда появляются ошибки 500 при нагрузке. Может ли это быть связано с нехваткой RAM?

Accepted Answer

Да, нехватка RAM вполне может проявляться как ошибки 500 под нагрузкой — особенно если процессы приложения начинают падать (OOM), резко уходят в swap или не могут выделить память и возвращают 5xx через веб‑сервер. Но 500 — не «чистый» признак памяти: он также бывает из‑за таймаутов, лимитов воркеров и проблем с БД, поэтому нужно подтвердить диагноз по метрикам и логам.

Как это устроено и какие признаки у нехватки памяти
Под нагрузкой растёт число параллельных запросов и фоновых задач, увеличивается суммарная память воркеров (PHP-FPM/Node/Java/.NET), кэшей, буферов и иногда — потребление БД на том же хосте. Когда RAM заканчивается, сценарии обычно такие:

OOM killer: ядро Linux принудительно убивает самый «тяжёлый» процесс (часто приложение/воркеры). На уровне веб‑сервера это выглядит как 500/502/504 (upstream prematurely closed connection, connection reset).
Активный swap: сервер не падает, но начинает «молотить» диском. Время ответа растёт, запросы не успевают, появляются таймауты и 5xx, CPU может быть невысоким, но задержки большие.
Лимиты памяти на процесс: например, PHP memory_limit, контейнерные лимиты cgroup/Kubernetes. Процесс не может выделить память и возвращает ошибку уровня приложения, которую фронт проксирует как 500.
Фрагментация/утечки: память постепенно «утекает» между релизами или в течение дня, и ошибки проявляются не сразу, а после роста uptime/нагрузки.

Типовые сигналы, что дело именно в RAM:

В момент 5xx свободная память близка к нулю и растёт swap used.
В логах ядра есть Out of memory, Killed process.
В логах веб‑сервера/аппа: cannot allocate memory, upstream prematurely closed connection, внезапные рестарты воркеров.
Нагрузочные пики сопровождаются ростом RSS у воркеров и увеличением их количества (например, PHP-FPM children, gunicorn workers, Node cluster).

Практически: как быстро подтвердить или опровергнуть нехватку RAM

Сопоставьте время 500 с метриками (хотя бы за 24–72 часа): RAM used, swap used, major page faults, load average, iowait, количество процессов/воркеров.
Проверьте OOM события на Linux: сообщения ядра в dmesg/journal (ищите oom, killed process). Если OOM есть — это практически прямое подтверждение.
Посмотрите swap и давление на память: если swap начинает активно расти во время пиков — проблема либо в объёме RAM, либо в настройках воркеров/кэшей, либо в утечке.
Проверьте конфиг воркеров:

PHP-FPM: max_children, max_requests (перезапуск воркера после N запросов снижает эффект утечек), реальные RSS одного child.
Java: Xmx/Xms, GC-паузы, не упирается ли контейнер в лимит.
Node/Python/.NET: количество воркеров и их память на запрос.

Изолируйте источники потребления: часто память «съедает» не веб‑апп, а co-located сервисы (БД, Elasticsearch, Redis) на том же сервере, либо системный page cache при большом IO.

Если после сопоставления видно: пик 5xx → рост RAM/swap → OOM/рестарты воркеров, можно уверенно говорить о связи с памятью.

Что делать бизнесу/команде (по приоритету)

Сначала стабилизировать: увеличьте RAM или временно уменьшите параллелизм (лимиты воркеров), чтобы убрать 500 в пике и не терять продажи/лиды.
Затем привести воркеры к прогнозируемому потреблению: оцените «память на один воркер» и выставьте max_children так, чтобы суммарно укладываться в RAM с запасом (и с учётом БД/кэшей/агентов мониторинга).
Уберите утечки и тяжёлые места: ограничьте размер in-memory кэшей, проверьте обработку больших файлов/ответов, включите ротацию/лимиты в очередях и фоновых задачах.
Разведите роли (если всё на одной машине): вынесите БД/поиск/кэш с веб‑сервера, либо примените контейнерные лимиты, чтобы один сервис не «убивал» другой.
Поставьте алерты: по swap, по OOM events, по резкому росту RSS у ключевых процессов, по 5xx rate. Это даст раннее предупреждение до падения.

Типичные ошибки, из-за которых 500 ошибочно списывают на RAM

Смотрят только на “free memory” в Linux и пугаются: часть памяти занята под cache/buffers — важнее смотреть на наличие OOM, swap и давление на память.
Не различают 500 и 502/504: при падении upstream чаще видны 502/504, но некоторые схемы логирования/обработки превращают это в 500 — нужно смотреть логи nginx/app вместе.
Увеличивают воркеры “чтобы держать нагрузку”, не учитывая память на воркер — итогом становится OOM и больше ошибок.
Игнорируют лимиты контейнеров: в Kubernetes/ Docker OOM может происходить при «вроде бы свободной» памяти на узле из-за лимита конкретного контейнера.

Если вы скажете стек (nginx+php-fpm, Node, Java и т.п.), ОС/контейнеры и пришлёте 2–3 строки из error.log вокруг 500, я подскажу, какие именно метрики/параметры в вашем случае быстрее всего подтвердят нехватку RAM.