Скільки оперативної пам’яті насправді потрібно для серверів та VPS у 2025 році?

Визначення обсягу оперативної пам'яті — це арифметика робочого навантаження, а не тест продуктивності. Якщо ви виділите забагато, то платитимете за невикористані ресурси. Якщо ж виділите замало, ваші процеси будуть зупинені, база даних працюватиме з диска замість пам'яті, або швидкість роботи ваших контейнерів буде обмежена. Цей посібник містить конкретні діапазони обсягів оперативної пам’яті для найпоширеніших робочих навантажень (веб-хостинг, бази даних, віртуалізація, контейнери, інференція штучного інтелекту та ігрові сервери), а також правила, якими слід керуватися під час визначення обсягу для навантажень, що не входять до цього переліку.

Яку роль відіграє оперативна пам’ять (RAM) у сервері

Оперативна пам'ять зберігає все, над чим сервер активно працює. Це пам'ять процесів для веб-серверів, механізмів баз даних та фонових демонів; кеш сторінок на рівні ОС та буфери вводу-виводу диска; пам'ять виконання для додатків та контейнерів; а також блоки пам'яті, що виділяються віртуальним машинам або робочим навантаженням контейнерів.

Відмінність у підборі обсягу оперативної пам’яті від підбору обсягу процесора полягає в режимі відмови. Якщо вичерпається потужність процесора, процеси сповільнюються. Якщо вичерпається оперативна пам’ять, ядро або переводить дані у файловий обмін (що сповільнює роботу), або механізм OOM-killer вибирає жертву та завершує її роботу. Перший варіант сприймається як неприємний. Другий призводить до втрати даних. Забезпечення оперативної пам’яті з запасом — це не просто приємна опція, а те, що запобігає повній відмові системи під навантаженням.

Оперативна пам’ять залежно від навантаження

Веб-сервери та сервери додатків

• Легкий стек 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, який за замовчуванням непомітно займає до половини системної оперативної пам’яті та конкурує з виділеними ресурсами для гостьових систем (наш посібник з налаштування ARC для ZFS містить правильні обмеження для робочих навантажень гіпервізора).

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

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

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

Інференція ШІ та ML

• Невеликі моделі (квантований 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 із конфігураціями з великим об’ємом оперативної пам’яті та необмеженою пропускною здатністю у багатьох регіонах.