Вимоги до RAM виділеного сервера: короткий огляд
RAM — це робочий простір, який використовується ядром Linux, процесами застосунків, кешем файлової системи, базами даних, контейнерами та фоновими завданнями. Сервер може використовувати майже всю доступну пам’ять і при цьому залишатися працездатним, оскільки Linux навмисно використовує невикористану RAM для кешу сторінок. Попереджувальними ознаками є постійна активність swap, завершення процесів через нестачу пам’яті, високий час очікування диска та зростання затримки зі збільшенням кількості одночасних користувачів.
Хороша ціль для підбору конфігурації — підтримувати нормальне пікове використання нижче 70–80% фізичної RAM. Це залишає запас для сплесків трафіку, запланованих завдань, кешу файлової системи, буферів баз даних і перезапуску збійного процесу. Сервери, що стабільно працюють із використанням пам’яті понад 90%, можуть функціонувати доти, доки резервне копіювання, розгортання, запит до бази даних або сплеск кількості гравців не спричинить swap чи завершення процесу OOM killer ядра.
Висновок: обирайте RAM відповідно до наведеного нижче масштабу навантаження, а потім додайте 25–50% запасу, якщо трафік зростає, резервні копії виконуються локально або кілька сервісів працюють на одному виділеному сервері.
| Масштаб навантаження | Рекомендована конфігурація | Типове виділення пам’яті | Приклади |
|---|---|---|---|
| Один легкий сервіс | 4–8 ядер CPU, 16 GB RAM, 240 GB NVMe | 2–8 GB активного використання | Невелика група сайтів WordPress, VPN, вузол моніторингу, один невеликий ігровий сервер |
| Невеликий production-стек | 6–8 ядер CPU, 32 GB RAM, 480 GB NVMe | 12–24 GB активного використання | Вебхостинг, поштовий сервер, хост Docker, 2–4 ігрові інстанси, невелика база даних PostgreSQL або MySQL |
| Застосунок або база даних, що зростає | 8–12 ядер CPU, 64 GB RAM, 1 TB NVMe | 28–50 GB активного використання | Завантажений магазин WooCommerce, SaaS-застосунок, CI runners, кеш Redis, база даних середнього розміру |
| Висока конкурентність або кілька сервісів | 12–16 ядер CPU, 128 GB RAM, 2 TB NVMe | 60–100 GB активного використання | Хост віртуалізації, велика ігрова спільнота, поштова платформа, база даних із високим трафіком, обробка відео |
| Платформа з інтенсивним використанням пам’яті | 16–32 ядер CPU, 256 GB RAM або більше, 2 TB+ корпоративний NVMe | 140–220 GB активного використання | Великі набори даних PostgreSQL/MySQL, кластери Elasticsearch, аналітика, щільно розміщені VM, вузли приватної хмари |
Як RAM використовується на виділеному сервері
Пам’ять застосунків — лише частина загального обсягу. Linux використовує RAM для кешу сторінок, який зберігає нещодавно відкриті файли, сторінки баз даних, журнали та ресурси доступними без повторного читання з диска. Це корисно: база даних, що має достатньо RAM для кешування свого робочого набору даних, може відповідати на багато запитів читання значно швидше, ніж та, що постійно отримує сторінки зі сховища NVMe.
- Операційна система та сервіси: Мінімальна інсталяція Linux може використовувати від 500 MB до 2 GB, але панелі керування, антивірусні інструменти, агенти моніторингу та клієнти резервного копіювання потребують більше.
- Вебстек: Nginx зазвичай легкий, тоді як Apache з prefork PHP може споживати значний обсяг пам’яті на кожен одночасний запит. Ліміти PHP-FPM роблять використання більш передбачуваним.
- Бази даних: MySQL, MariaDB і PostgreSQL використовують налаштовані буферні пули та пам’ять на кожне з’єднання. Невдалі ліміти з’єднань можуть швидко вичерпати пам’ять.
- Контейнери та віртуальні машини: Контейнери Docker використовують спільне ядро хоста, але кожній віртуальній машині потрібна призначена гостьова RAM і певні накладні витрати гіпервізора.
- Кеші: Redis, Memcached, Elasticsearch і кеші застосунків навмисно обмінюють RAM на нижчу затримку.
- Кеш файлової системи: Linux автоматично вивільняє кеш за нестачі ресурсів, але кеш цінний для вебресурсів, складання пакетів і даних, які часто читаються.
Перевіряйте фактичну ситуацію за допомогою free -h, vmstat 1 і ps aux --sort=-%mem | head -20. У виводі free -h зосередьтеся на значенні available, а не вважайте весь кеш недоступною пам’яттю.
RAM за типом навантаження
Вебхостинг і CMS-сайти: 16–64 GB
Виділений сервер, що розміщує кілька маловідвідуваних сайтів WordPress, Laravel або статичних сайтів, може добре працювати з 16 GB RAM за умови налаштування Nginx, PHP-FPM і невеликої бази даних. Переходьте на 32 GB, коли сервер розміщує кілька динамічних сайтів, запускає панель керування хостингом, обробляє часті cron-завдання або підтримує трафік електронної комерції. Сервер із 64 GB є розумовою базовою конфігурацією для багатьох завантажених стеків WooCommerce, Magento або власних застосунків, оскільки дозволяє кешувати базу даних і залишає місце для PHP-воркерів.
Оцінюйте можливості PHP-FPM за фактичним розміром процесів. Якщо кожен воркер використовує 120 MB, а сервер безпечно резервує 6 GB для ОС, бази даних, кешу та запасу на машині з 32 GB, виділення 12 GB для PHP дозволяє мати приблизно 100 воркерів. Не встановлюйте 100 воркерів автоматично: ядра CPU, можливості бази даних вище за стеком і тривалість запитів також обмежують корисну конкурентність.
Бази даних: від 32 GB до 256 GB або більше
Розмір бази даних визначається активним робочим набором, а не лише загальним розміром диска. База даних на 500 GB може добре працювати з 64 GB RAM, якщо активними є лише 30 GB індексів і нещодавно запитуваних рядків. І навпаки, база даних на 40 GB може потребувати 128 GB, якщо одночасно виконуються аналітичні запити, багато з’єднань і великі JOIN-операції.
Для MySQL або MariaDB починайте з буферного пулу InnoDB розміром приблизно 50–70% RAM на сервері, призначеному лише для бази даних. На виділеному сервері бази даних із 64 GB RAM буферний пул 36–44 GB є практичним початковим діапазоном. Залишайте пам’ять для ОС, буферів з’єднань, тимчасових таблиць, резервних копій і моніторингу. PostgreSQL потребує аналогічної дисципліни: shared buffers — лише один компонент, тоді як work_mem множиться на сортування, хеші та одночасні запити.
Ігрові сервери: 16–128 GB
Використання пам’яті ігровим сервером більше залежить від рушія гри, модів, розміру мапи та кількості гравців, ніж від швидкості мережі. Один vanilla-сервер Minecraft може вміститися у 4–8 GB, але модпаки та великі світи зазвичай потребують 10–16 GB на інстанс. Виділений сервер із 32 GB RAM може підтримувати невелику спільноту та пов’язану вебпанель, тоді як 64 GB краще підходять для кількох модифікованих інстансів або більшої бази гравців.
Rust, ARK: Survival Evolved і сервери виживання з великою кількістю модів можуть використовувати 16–32 GB або більше для одного активного інстансу. Для спільноти, що керує кількома ігровими світами, 128 GB забезпечують безпечніший запас для консолідації. Однопотокова продуктивність CPU залишається критичною для ігор, чутливих до tick rate, тому більша кількість RAM не повинна замінювати достатню кількість високочастотних ядер CPU.
Поштові сервери: 16–64 GB
Невеликий поштовий сервер із Postfix, Dovecot, Rspamd, антивірусним скануванням і фільтрацією спаму може починати з 16 GB. Використовуйте 32 GB для production-поштової платформи з багатьма активними поштовими скриньками, скануванням вкладень і локальними чергами повідомлень. Обирайте 64 GB, якщо сервер обробляє великі обсяги вхідної пошти, зберігає значний обсяг даних спам-фільтра або локально запускає служби баз даних і вебпошти. Поштові системи також потребують швидкого сховища та ретельного налаштування DNS, reverse DNS, SPF, DKIM і DMARC; лише RAM не визначає якість доставки.
Стримінгові та медіасервіси: 32–128 GB
Відеостримінг часто стає обмеженим CPU під час транскодування, але RAM важлива для одночасних завдань ffmpeg, мініатюр, баз даних метаданих і кешування. Медіасервер із direct play може починати з 16–32 GB. Сервер, що виконує кілька транскодувань 1080p, краще оснащувати 32–64 GB, тоді як транскодування 4K, великі медіатеки або кілька одночасних завдань кодування можуть виправдати 128 GB. Апаратне кодування може зменшити навантаження на CPU, але не усуває потреби в запасі пам’яті.
CI/CD, збірки та платформи розробки: 32–128 GB
Завдання компіляції, збирання образів контейнерів, браузерні тести та паралельні CI runners споживають пам’ять ривками. Виділений сервер із 32 GB підходить для одного або двох помірних runners. Використовуйте 64 GB для паралельних збірок і самостійно розміщених Git-сервісів, а 128 GB — коли кілька runners одночасно компілюють великі проєкти Java, Android, Rust, C++, або frontend-проєкти. Налаштовуйте конкурентність runner відповідно до CPU та RAM; вісім завдань на восьми ядрах небезпечні, якщо кожна збірка може споживати 6 GB.
Віртуалізація та самостійно розміщені стеки застосунків: 64–256 GB
Хост віртуалізації потребує фізичної RAM для кожного гостя, а також накладних витрат хоста й кешу. Наприклад, шість VM, яким призначено по 6 GB, потребують щонайменше 36 GB ще до врахування гіпервізора, кешу файлової системи та зростання. Виділений сервер із 64 GB є розумовою відправною точкою для кількох production VM. Обирайте 128 GB або 256 GB для щільніших парків VM, worker-вузлів Kubernetes або самостійно розміщених стеків із Nextcloud, GitLab, моніторингом, базами даних і об’єктним сховищем.
Методологія та інструменти тестування продуктивності
Рішення щодо RAM слід перевіряти за допомогою відтворюваного бенчмарку, а не вгадувати на основі одного графіка панелі моніторингу. Наведений нижче еталонний профіль використовує 8-ядерний виділений сервер, 64 GB DDR5 RAM, накопичувач NVMe на 1 TB і мережевий порт 1 Gbps. Тести виконуються на інакше не завантаженому хості 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тестує пропускну здатність копіювання пам’яті. - Дисковий I/O:
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, диска, мережі та пам’яті
| Тест | Еталонний результат | Що він показує | Відношення до RAM |
|---|---|---|---|
| Sysbench CPU, 8 потоків | 1,180 подій за секунду | Обчислювальна потужність для коду застосунків, стиснення та ігрових tick-ів | Більше RAM не збільшує цей результат, якщо не відбувався swap |
| Копіювання пам’яті Sysbench | 31.6 GiB/s | Пропускна здатність пам’яті для навантажень з інтенсивним кешуванням і паралельних навантажень | Корисно для баз даних, збірок і віртуальних машин |
| fio випадкове читання 4 KiB | 286,000 IOPS, 1.09 GiB/s | Швидкодія сховища для малих блоків | Недостатня RAM призводить до того, що більше операцій читання досягають цього рівня |
| fio послідовний запис 1 MiB | 1.72 GiB/s | Пропускна здатність запису для резервних копій, медіа та великих файлів | Буфери запису згладжують короткі сплески, але не замінюють надійне сховище |
| iperf3, 4 потоки, порт 1 Gbps | 941 Mbps | Практична пропускна здатність TCP після накладних витрат протоколу | Велика кількість з’єднань потребує пам’яті для буферів сокетів |
| wrk, 100 з’єднань, кешований PHP endpoint | 1,850 запитів/секунду, p95 74 ms | Відгук вебстеку за контрольованого навантаження | Кеш сторінок і буфери бази даних зменшують очікування диска |
Ці показники демонструють, чому RAM опосередковано впливає на продуктивність застосунків. Накопичувач NVMe швидкий, але сторінка бази даних, що надходить із пам’яті, взагалі не потребує запиту до сховища. Якщо недостатня RAM примушує використовувати swap I/O, затримка під навантаженням може зрости з мілісекунд до сотень мілісекунд.
Вплив на продуктивність реальних застосунків
Вебсайт із базою даних: Сервер із 32 GB, який резервує 16 GB для буферів MySQL, 6 GB для PHP-FPM, а решту для ОС і кешу, може передбачувано обробляти помірний динамічний трафік. Якщо той самий сайт отримує спричинений кампанією сплеск трафіку й використання пам’яті досягає 95%, нові PHP-воркери та тимчасові таблиці бази даних можуть перевести хост у swap. Конфігурація з 64 GB часто покращує затримку p95 більше, ніж додаткові ядра CPU, оскільки зберігає в кеші гарячі сторінки бази даних і вебресурси.
Спільнота Minecraft: Сервер із 16 GB може запускати один модифікований інстанс на 10 GB, але заплановані збереження світу та активність плагінів залишають мало резерву. Сервер із 32 GB надає простір для Java heap, зберігаючи пам’ять для кешу Linux та інструментів керування. Призначення Java heap кожного доступного GB є контрпродуктивним, оскільки хост також потребує пам’яті.
Аналітичне навантаження PostgreSQL: Сервер звітності зі 100 GB індексів і таблиць, до яких часто звертаються, суттєво виграє від 128 GB RAM. Він може зберігати більше гарячих даних у кеші, зменшуючи кількість випадкових читань NVMe під час роботи інформаційних панелей і генерування звітів. Плани запитів та індекси все ще необхідні; додавання RAM не може виправити неефективне повне сканування таблиці.
CI-хост для збірок: Чотири одночасні збірки контейнерів, що використовують по 7 GB, можуть перевищити можливості сервера з 32 GB після врахування хоста, кешу Docker і тестових процесів. Конфігурація з 64 GB підтримує ті самі завдання з практичним запасом, тоді як 128 GB доцільні, якщо паралельно виконуються браузерні тести та компіляція.
Рекомендації з оптимізації
Вимірюйте тиск на пам’ять, а не лише використану RAM
Запускайте free -h, vmstat 1 і sar -r 1 60 під час пікового навантаження. У vmstat постійні ненульові значення si і so вказують на активність swap-in та swap-out. Переглядайте події OOM ядра за допомогою journalctl -k | grep -i oom.
Встановлюйте ліміти для кожного сервісу
Використовуйте pm.max_children PHP-FPM, ліміти пам’яті Docker, MemoryMax= systemd, пули з’єднань баз даних і ліміти конкурентності CI runner. Контрольована черга безпечніша, ніж дозвіл одному сервісу спожити всю фізичну пам’ять і завершити непов’язані процеси.
Консервативно налаштовуйте пам’ять бази даних
Встановлюйте розмір буферних пулів на основі виміряного навантаження та залишайте запас для пам’яті з’єднань. Моніторте MySQL за допомогою mysqladmin extended-status або PostgreSQL за допомогою pg_stat_database. Додавайте індекси та виправляйте дорогі запити, перш ніж вважати, що єдиною відповіддю є більший обсяг RAM.
Використовуйте швидке сховище NVMe та уникайте постійного swap
NVMe зменшує втрати від промахів кешу, резервних копій і читань бази даних, але не може зробити swap прийнятним для завантаженого production-сервісу. Зберігайте невеликий swap-розділ як аварійний захист, встановлюйте консервативне значення swappiness там, де це доречно, і досліджуйте будь-яке постійне використання swap.
Розділяйте несумісні навантаження
База даних, воркер транскодування, CI runner та ігровий сервер можуть конкурувати за RAM і CPU в непередбачуваний час. Використовуйте окремі виділені сервери для постійних навантажень, критичних до ізоляції. VPS часто достатньо для VPN з низьким трафіком, вузла моніторингу, невеликого статичного сайту або одного легкого сервісу, але виділене обладнання краще підходить для активних баз даних, ігрових спільнот, великих систем збірки та production-платформ із кількома сервісами.
Плануйте зростання та обслуговування
Передбачайте пам’ять для відновлення баз даних, резервного копіювання, оновлення пакетів, обробки журналів, сканування безпеки та сплесків трафіку. Якщо пікове використання вже перевищує 80% RAM, переходьте на наступний рівень, перш ніж терміновий інцидент змусить виконати оновлення.