Сколько оперативной памяти действительно потребуется для серверов и VPS в 2025 году?

Определение объема оперативной памяти — это расчет рабочей нагрузки, а не тест производительности. Если вы переоцените потребности, то будете платить за простаивающие ресурсы. Если недооцените — ваши процессы будут прерываться, база данных будет работать с диска вместо памяти, или ваши контейнеры будут ограничены в производительности. В данном руководстве приведены конкретные диапазоны объёмов оперативной памяти для наиболее распространённых рабочих нагрузок (веб-хостинг, базы данных, виртуализация, контейнеры, вычисления искусственного интеллекта и игровые серверы), а также правила, которыми следует руководствоваться при определении объёма для нагрузок, не указанных в списке.

Какую роль играет оперативная память (RAM) в сервере

Оперативная память хранит всё, с чем сервер активно работает. Это память процессов для веб-серверов, движков баз данных и фоновых демонов; кэш страниц на уровне ОС и буферы дискового ввода-вывода; память для выполнения приложений и контейнеров; а также фрагменты памяти, выделяемые виртуальным машинам или контейнерным рабочим нагрузкам.

Отличие определения объёма ОЗУ от определения объёма ЦП заключается в режиме сбоя. Если не хватает ЦП, процессы замедляются. Если не хватает ОЗУ, ядро либо использует свопинг (медленно), либо OOM-киллер выбирает жертву и завершает её работу. Первый вариант неприятен. Во втором случае происходит потеря данных. Выделение ОЗУ с запасом — это не просто «приятная опция», а то, что предотвращает полный коллапс системы под нагрузкой.

Оперативная память в зависимости от рабочей нагрузки

Веб-серверы и серверы приложений

• Легкий стек LAMP или LEMP: от 1 до 2 ГБ
• WordPress или CMS с кэшированием (например, Redis): от 2 до 4 ГБ
• Электронная коммерция (Magento, WooCommerce): от 4 до 8 ГБ
• Приложения на Node.js, Django или Rails: от 2 до 6 ГБ

Для уровней кэширования, таких как Redis или Varnish, требуется собственная оперативная память в дополнение к базовому объему, необходимому для приложения. Рабочие процессы PHP-FPM, подключения к базам данных и обратные прокси одновременно потребляют память, поэтому важным показателем является пиковая параллельность, а не объем памяти в режиме простоя.

Серверы баз данных (SQL и NoSQL)

• MySQL или PostgreSQL (небольшие): от 4 до 8 ГБ
• MySQL или PostgreSQL (крупные или с высокой нагрузкой): от 16 до 64 ГБ
• MongoDB или Redis (с акцентом на работу в памяти): от 32 до 128 ГБ или более
• Узлы Elasticsearch или OpenSearch: от 32 до 128 ГБ на узел

Цель состоит в том, чтобы рабочий набор, индексы и часто используемые строки хранились в оперативной памяти. Как только что-либо из этого попадает на диск, задержка увеличивается на несколько порядков, независимо от скорости SSD.

Хосты виртуализации (Proxmox, VMware, Hyper-V)

• Легкие виртуальные машины под Linux: от 2 до 4 ГБ на каждую виртуальную машину
• Виртуальные машины Windows: от 8 до 12 ГБ на каждую виртуальную машину
• Панели хостинга (cPanel, Plesk, DirectAdmin): от 4 до 8 ГБ на экземпляр
• Хосты контейнеров KVM или LXC: от 32 до 128 ГБ и более

Всегда резервируйте от 4 до 8 ГБ для самой хост-ОС, помимо выделений для гостевых систем. Контейнеры используют меньше оперативной памяти на одну рабочую нагрузку, чем полноценные виртуальные машины, но масштабируются иначе, поэтому планируйте с учетом плотности и резерва на пиковые нагрузки, а не исходя из размера каждого отдельного контейнера. Если хост использует ZFS, также учитывайте ARC, который по умолчанию незаметно занимает до половины системной оперативной памяти и конкурирует с выделенными объёмами для гостевых систем (в нашем руководстве по настройке ZFS ARC описаны правильные ограничения для рабочих нагрузок гипервизора).

Контейнеры и микросервисы (Docker, Kubernetes)

• Простые стеки Docker (веб, приложение, БД): от 8 до 16 ГБ
• Узлы Docker Swarm или K3s на периферии: от 16 до 32 ГБ
• Рабочие узлы Kubernetes: от 32 до 128 ГБ
• Запускающие агенты CI/CD и агенты сборки (GitLab, Jenkins): от 8 до 32 ГБ на каждый запускающий агент

Следите за утечками памяти в контейнерах, работающих в течение длительного времени. Рабочие нагрузки на основе JVM, такие как Kafka и Elasticsearch, требуют более высоких базовых значений, поскольку объем кучи будет расти до тех пор, пока вы это допускаете, и зачастую он оказывается выше, чем ожидалось.

Вычисления в области ИИ и машинного обучения

• Небольшие модели (квантованный BERT, Llama 7B): от 16 до 32 ГБ
• Средние модели (от 13B до 30B, квантованные): от 64 до 128 ГБ
• Крупные модели (40B+ или неквантованные модели среднего диапазона): от 128 до 512 ГБ и более
• Вычисления на GPU (Stable Diffusion, Whisper): от 32 до 128 ГБ в зависимости от степени разгрузки

Квантование переносит нагрузку на память с графического процессора на оперативную память процессора, поэтому системные требования существенно меняются в зависимости от того, обрабатываете ли вы данные в формате fp16 на графическом процессоре или в 4-битном формате на процессоре. Размер пакетной обработки и длина подсказки также увеличивают эти показатели. В нашем руководстве по хостингу инференции ИИ более подробно рассматривается вопрос подбора оборудования в соответствии с размером модели.

Игровые серверы

• Minecraft (базовая версия): от 2 до 4 ГБ
• Minecraft (с модами): от 6 до 16 ГБ
• Rust, ARK или 7 Days to Die: от 8 до 16 ГБ
• Узлы хостинга с несколькими экземплярами: от 32 до 64 ГБ

Специализированные рабочие нагрузки

• Транскодирование видео (FFmpeg, Plex): от 16 до 64 ГБ
• Серверы резервного копирования или создания моментальных снимков: от 8 до 16 ГБ, больше — при использовании механизмов дедупликации
• Брандмауэр или IDS (pfSense, Suricata): от 2 до 8 ГБ, больше — при использовании NetFlow или полного логгирования пакетов

Не полагайтесь на подкачку

Обменная память работает в 10–100 раз медленнее, чем оперативная память. Она служит в качестве «страховочной сетки», чтобы ядро могло куда-то перенести данные при резком росте нагрузки на память, а не как способ расширения доступной памяти. Если сервер задействует обменную память при нормальной нагрузке, это означает, что ему не хватает ресурсов — и точка. В статье «Как взаимодействуют подкачка Linux, OOM-киллер и cgroups» подробно описаны возможные сценарии сбоев.

Как точно рассчитать объём оперативной памяти

1. Измеряйте пиковые значения, а не средние. Используйте htop, free -m, vmstat 1или метрики Kubernetes, чтобы определить пиковое использование в течение полного цикла трафика. Важны как дневные пики, так и еженедельные пакеты данных, и ежемесячные циклы выставления счетов.
2. Предусмотрите запас на рост: от 20% до 50% для масштабирования приложений. Для баз данных масштабируйте объем памяти в зависимости от размера набора данных, а не от частоты запросов. Для многопользовательских платформ рассчитайте объем памяти на одного клиента и умножьте его.
3. Планируйте с учётом допустимого режима сбоев. Реплика для чтения, испытывающая нехватку ОЗУ, работает с пониженной производительностью. Основной сервер базы данных, испытывающий нехватку ОЗУ, приводит к сбоям в запросах и может вызвать отказ приложений. Направляйте ресурсы ОЗУ туда, где последствия перегрузки наиболее значительны.

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

FDC предлагает выделенные серверы и VPS с конфигурациями с большим объёмом оперативной памяти и неограниченной пропускной способностью в нескольких регионах.