Оперативная память выделенного сервера: сколько нужно для вашей нагрузки

Требования к оперативной памяти выделенного сервера: краткий обзор

Оперативная память — это рабочее пространство, используемое ядром Linux, процессами приложений, кэшем файловой системы, базами данных, контейнерами и фоновыми задачами. Сервер может использовать почти всю доступную память, не имея проблем, поскольку Linux намеренно использует свободную ОЗУ для кэша страниц. Тревожными признаками являются постоянная активность подкачки, завершение процессов из-за нехватки памяти, высокая задержка диска и рост задержки при увеличении числа одновременных пользователей.

Хорошая цель при подборе конфигурации — поддерживать обычное пиковое использование ниже 70–80% физической ОЗУ. Это оставляет место для всплесков трафика, запланированных задач, кэша файловой системы, буферов базы данных и перезапуска завершившегося процесса. Серверы, постоянно работающие при использовании памяти выше 90%, могут функционировать нормально до тех пор, пока резервное копирование, развертывание, запрос к базе данных или всплеск числа игроков не вызовет подкачку либо убийца OOM ядра не завершит процесс.

Итог: выбирайте объем ОЗУ исходя из масштаба рабочей нагрузки ниже, затем добавьте 25–50% запаса, если трафик растет, резервное копирование выполняется локально или несколько служб используют один и тот же выделенный сервер.

Как используется ОЗУ на выделенном сервере

Память приложений — лишь часть общего объема. Linux использует ОЗУ для кэша страниц, который хранит недавно доступные файлы, страницы базы данных, журналы и ресурсы, позволяя обращаться к ним без повторного чтения с диска. Это полезно: база данных, которой достаточно ОЗУ для кэширования рабочего набора данных, может выполнять многие операции чтения значительно быстрее, чем база, постоянно загружающая страницы из NVMe-хранилища.

• Операционная система и службы: минимальная установка Linux может использовать от 500 МБ до 2 ГБ, но панели управления, антивирусы, агенты мониторинга и клиенты резервного копирования добавляют нагрузку.
• Веб-стек: Nginx обычно потребляет мало памяти, тогда как Apache с prefork PHP может использовать значительный объем памяти для каждого одновременного запроса. Ограничения PHP-FPM делают использование памяти более предсказуемым.
• Базы данных: MySQL, MariaDB и PostgreSQL используют настроенные буферные пулы, а также память для каждого соединения. Неправильно заданные ограничения соединений могут быстро исчерпать память.
• Контейнеры и виртуальные машины: контейнеры Docker используют общее ядро хоста, но каждой виртуальной машине требуется выделенная гостевая ОЗУ плюс небольшой объем памяти для гипервизора.
• Кэши: Redis, Memcached, Elasticsearch и кэши приложений намеренно обменивают ОЗУ на меньшую задержку.
• Кэш файловой системы: Linux автоматически освобождает кэш при нехватке памяти, но кэш важен для веб-ресурсов, сборки пакетов и часто читаемых данных.

Проверяйте фактическое состояние с помощью free -h, vmstat 1 и ps aux --sort=-%mem | head -20. В выводе free -h обращайте внимание на значение available, а не считайте весь кэш недоступной памятью.

Объем ОЗУ в зависимости от рабочей нагрузки

Веб-хостинг и сайты на CMS: 16–64 ГБ

Выделенный сервер с несколькими сайтами WordPress, Laravel или статическими сайтами с небольшим трафиком может хорошо работать с 16 ГБ ОЗУ, если настроены Nginx, PHP-FPM и небольшая база данных. Переходите на 32 ГБ, если сервер размещает несколько динамических сайтов, работает с панелью управления хостингом, обрабатывает частые задания cron или поддерживает трафик интернет-магазина. Сервер на 64 ГБ — разумная базовая конфигурация для многих популярных стеков WooCommerce, Magento или пользовательских приложений, поскольку он позволяет кэшировать базу данных и оставляет место для рабочих процессов PHP.

Оценивайте возможности PHP-FPM по реальному размеру процессов. Если каждый рабочий процесс использует 120 МБ, а сервер безопасно резервирует 6 ГБ для ОС, базы данных, кэша и запаса на машине с 32 ГБ, выделение 12 ГБ для PHP позволяет использовать примерно 100 рабочих процессов. Не устанавливайте автоматически 100 процессов: количество ядер CPU, возможности внешней базы данных и длительность запросов также ограничивают полезную параллельность.

Базы данных: от 32 до 256 ГБ и более

Размер базы данных определяется активным рабочим набором, а не просто общим размером диска. База данных объемом 500 ГБ может хорошо работать с 64 ГБ ОЗУ, если активно используются только 30 ГБ индексов и недавно запрошенных строк. И наоборот, базе данных объемом 40 ГБ может потребоваться 128 ГБ, если одновременно выполняются аналитические запросы, используется много соединений и выполняются большие объединения.

Для MySQL или MariaDB начните с буферного пула InnoDB размером около 50–70% ОЗУ на сервере, выделенном только под базу данных. На выделенном сервере базы данных с 64 ГБ практичным начальным диапазоном будет буферный пул 36–44 ГБ. Оставьте память для ОС, буферов соединений, временных таблиц, резервного копирования и мониторинга. PostgreSQL требует аналогичного подхода: shared buffers — лишь один из компонентов, тогда как work_mem умножается на количество сортировок, хеш-операций и параллельных запросов.

Игровые серверы: 16–128 ГБ

Использование памяти игровым сервером сильнее зависит от игрового движка, модификаций, размера карты и числа игроков, чем от скорости сети. Один сервер Minecraft без модификаций может работать с 4–8 ГБ, однако сборки модификаций и большие миры обычно требуют 10–16 ГБ на экземпляр. Выделенный сервер с 32 ГБ ОЗУ может поддерживать небольшое сообщество и связанную с ним веб-панель, а 64 ГБ лучше подходят для нескольких модифицированных экземпляров или большей аудитории игроков.

Rust, ARK: Survival Evolved и сильно модифицированные серверы выживания могут использовать 16–32 ГБ или больше на один активный экземпляр. Для сообщества, работающего с несколькими игровыми мирами, 128 ГБ обеспечивают более безопасный запас для консолидации. Производительность CPU на одном ядре остается критически важной для игр, чувствительных к частоте обновления, поэтому больший объем ОЗУ не должен заменять достаточное количество высокочастотных ядер CPU.

Почтовые серверы: 16–64 ГБ

Небольшой почтовый сервер с Postfix, Dovecot, Rspamd, антивирусной проверкой и фильтрацией спама может начать работу с 16 ГБ. Используйте 32 ГБ для рабочей почтовой платформы с большим количеством активных почтовых ящиков, проверкой вложений и локальными очередями сообщений. Выбирайте 64 ГБ, если сервер обрабатывает большие входящие объемы, хранит обширные данные фильтрации спама или локально запускает службы базы данных и веб-почты. Почтовым системам также требуются быстрое хранилище и тщательная настройка DNS, обратного DNS, SPF, DKIM и DMARC; одно лишь количество ОЗУ не определяет качество доставки.

Потоковая передача и мультимедийные службы: 32–128 ГБ

Потоковая передача видео часто упирается в производительность CPU во время транскодирования, однако ОЗУ важна для одновременных заданий ffmpeg, миниатюр, баз метаданных и кэширования. Сервер мультимедиа с прямым воспроизведением может начать работу с 16–32 ГБ. Серверу, выполняющему несколько транскодирований 1080p, лучше иметь 32–64 ГБ, тогда как транскодирование 4K, большие медиатеки или несколько одновременных заданий кодирования могут оправдать 128 ГБ. Аппаратное кодирование снижает нагрузку на CPU, но не устраняет необходимость в запасе памяти.

CI/CD, сборка и платформы разработки: 32–128 ГБ

Задания компиляции, сборка образов контейнеров, браузерные тесты и параллельные CI-раннеры потребляют память всплесками. Выделенный сервер с 32 ГБ подходит для одного или двух умеренно нагруженных раннеров. Используйте 64 ГБ для параллельных сборок и самостоятельно размещаемых сервисов Git, а 128 ГБ — когда несколько раннеров одновременно компилируют крупные проекты на Java, Android, Rust, C++ или фронтенд-проекты. Настраивайте параллельность раннеров с учетом как CPU, так и ОЗУ: восемь заданий на восьми ядрах небезопасны, если каждое может потребить 6 ГБ.

Виртуализация и самостоятельно размещаемые стеки приложений: 64–256 ГБ

Хост виртуализации требует физической ОЗУ для каждой гостевой системы, а также памяти для самого хоста и кэша. Например, шесть виртуальных машин по 6 ГБ требуют не менее 36 ГБ без учета гипервизора, кэша файловой системы и роста нагрузки. Выделенный сервер с 64 ГБ — разумная отправная точка для нескольких рабочих виртуальных машин. Выбирайте 128 или 256 ГБ для более плотного размещения виртуальных машин, рабочих узлов Kubernetes или самостоятельно размещаемых стеков с Nextcloud, GitLab, мониторингом, базами данных и объектным хранилищем.

Быстрый выбор

Ищете сервер, который просто работает?

Valebyte VPS — NVMe, поддержка 24/7, запуск за 60 секунд.

Тарифы VPS

Методика и инструменты тестирования производительности

Решения об объеме ОЗУ следует проверять с помощью повторяемого теста, а не принимать на основе одного графика панели мониторинга. В приведенном ниже эталонном профиле используется выделенный сервер с 8-ядерным CPU, 64 ГБ памяти DDR5, накопителем NVMe на 1 ТБ и сетевым портом 1 Гбит/с. Тесты выполняются на не нагруженном Linux-хосте с использованием локального хранилища и повторяются три раза; приводится медианный результат. Результаты зависят от поколения CPU, модели NVMe, схемы RAID, маршрута до дата-центра, версии ядра и непредсказуемой нагрузки приложений.

• CPU: sysbench cpu --cpu-max-prime=20000 --threads=8 run измеряет пропускную способность вычислений простых чисел.
• Память: sysbench memory --memory-block-size=1M --memory-total-size=100G run тестирует пропускную способность копирования памяти.
• Дисковый ввод-вывод: fio --name=randread --filename=/srv/fio.test --size=20G --bs=4k --rw=randread --iodepth=32 --numjobs=4 --direct=1 --runtime=60 --time_based тестирует IOPS при случайном чтении без использования кэша страниц.
• Сеть: iperf3 -c benchmark.example.net -P 4 -t 30 измеряет пропускную способность TCP до подходящей удаленной точки. Тестируйте несколько географических местоположений.
• Нагрузка приложения: wrk -t4 -c100 -d60s https://server.example/ измеряет возможности веб-ответа при 100 одновременных соединениях.

Эталонные результаты тестирования CPU, диска, сети и памяти

Эти числа показывают, почему ОЗУ косвенно влияет на производительность приложений. NVMe-накопитель работает быстро, но страница базы данных, обслуженная из памяти, полностью исключает обращение к хранилищу. Если недостаток ОЗУ вынуждает использовать подкачку, задержка под нагрузкой может вырасти с миллисекунд до сотен миллисекунд.

Влияние на производительность приложений в реальных условиях

Сайт с базой данных: Сервер с 32 ГБ, который выделяет 16 ГБ под буферы MySQL, 6 ГБ под PHP-FPM, а оставшийся объем — под ОС и кэш, может предсказуемо обрабатывать умеренный динамический трафик. Если тот же сайт получает всплеск трафика из-за рекламной кампании и использование памяти достигает 95%, новые рабочие процессы PHP и временные таблицы базы данных могут перевести хост в режим подкачки. Конфигурация с 64 ГБ часто сильнее улучшает задержку p95, чем дополнительные ядра CPU, поскольку сохраняет часто используемые страницы базы данных и веб-ресурсы в кэше.

Сообщество Minecraft: Сервер с 16 ГБ может запускать один модифицированный экземпляр объемом 10 ГБ, но плановые сохранения мира и активность плагинов оставляют небольшой запас. Сервер с 32 ГБ дает Java-куче достаточно места, сохраняя память для кэша Linux и инструментов управления. Выделение каждого доступного гигабайта Java-куче контрпродуктивно, поскольку хосту также требуется память.

Аналитическая нагрузка PostgreSQL: Сервер отчетности со 100 ГБ часто используемых индексов и таблиц получает существенную пользу от 128 ГБ ОЗУ. Он может хранить больше востребованных данных в кэше, уменьшая количество случайных чтений NVMe во время работы панелей мониторинга и формирования отчетов. Планы запросов и индексы по-прежнему необходимы; добавление ОЗУ не исправит неэффективное полное сканирование таблицы.

Хост сборки CI: Четыре параллельные сборки контейнеров, использующие по 7 ГБ каждая, могут превысить объем сервера с 32 ГБ после учета хоста, кэша Docker и тестовых процессов. Конфигурация с 64 ГБ поддерживает те же задания с практичным запасом, а 128 ГБ подходят, если параллельно выполняются браузерные тесты и компиляция.

Быстрый выбор

Ищете сервер, который просто работает?

Valebyte VPS — NVMe, поддержка 24/7, запуск за 60 секунд.

Тарифы VPS

Рекомендации по оптимизации

Измеряйте давление на память, а не только использованный объем ОЗУ

Запускайте free -h, vmstat 1 и sar -r 1 60 во время пиковой нагрузки. В vmstat постоянно ненулевые значения si и so указывают на активность загрузки из подкачки и выгрузки в подкачку. Проверяйте события OOM ядра с помощью journalctl -k | grep -i oom.

Устанавливайте ограничения для каждой службы

Используйте pm.max_children PHP-FPM, ограничения памяти Docker, MemoryMax= systemd, пулы соединений баз данных и ограничения параллельности CI-раннеров. Контролируемая очередь безопаснее, чем ситуация, когда одна служба потребляет всю физическую память и завершает работу несвязанных процессов.

Настраивайте память базы данных консервативно

Устанавливайте размеры буферных пулов на основе измеренной нагрузки и оставляйте запас для памяти соединений. Отслеживайте MySQL с помощью mysqladmin extended-status или PostgreSQL с помощью pg_stat_database. Добавляйте индексы и исправляйте дорогостоящие запросы, прежде чем считать увеличение ОЗУ единственным решением.

Используйте быстрое NVMe-хранилище и избегайте постоянной подкачки

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

Разделяйте несовместимые рабочие нагрузки

База данных, обработчик транскодирования, CI-раннер и игровой сервер могут конкурировать за ОЗУ и CPU в непредсказуемые моменты. Для постоянных нагрузок, критичных к изоляции, используйте отдельные выделенные серверы. VPS часто достаточно для VPN с небольшим трафиком, узла мониторинга, небольшого статического сайта или одной легкой службы, но выделенное оборудование лучше подходит для активных баз данных, игровых сообществ, крупных систем сборки и рабочих платформ с несколькими службами.

Планируйте рост и обслуживание

Предусмотрите память для восстановления баз данных, резервного копирования, обновления пакетов, обработки журналов, проверок безопасности и всплесков трафика. Если пиковое использование уже превышает 80% ОЗУ, переходите на следующий уровень до того, как срочный инцидент вынудит выполнять обновление.