Ile pamięci RAM naprawdę potrzebujesz na serwery i VPS w 2025 roku?

Dobór wielkości pamięci RAM to obliczenia związane z obciążeniem, a nie test porównawczy. Jeśli prześcigniesz wymagania, zapłacisz za niewykorzystaną pojemność. Jeśli nie osiągniesz wymaganej wartości, procesy zostaną przerwane, baza danych będzie obsługiwać dane z dysku zamiast z pamięci, a kontenery zostaną ograniczone. Niniejszy przewodnik podaje konkretne przedziały pamięci RAM dla najczęściej spotykanych obciążeń (hosting stron internetowych, bazy danych, wirtualizacja, kontenery, wnioskowanie AI oraz serwery gier), a także zasady, których należy przestrzegać przy doborze pamięci RAM dla rozwiązań nieujętych na liście.

Rola pamięci RAM w serwerze

Pamięć RAM przechowuje wszystko, nad czym serwer aktualnie pracuje. Pamięć procesowa dla serwerów WWW, silników baz danych i demonów działających w tle. Pamięć podręczna stron na poziomie systemu operacyjnego oraz bufory operacji wejścia/wyjścia na dysku. Pamięć uruchomieniowa dla aplikacji i kontenerów. A także fragmenty pamięci przydzielane maszynom wirtualnym lub obciążeniom kontenerowym.

To, co odróżnia dobór wielkości pamięci RAM od doboru wielkości procesora, to sposób awarii. Gdy zabraknie mocy obliczeniowej procesora, procesy zwalniają. Gdy zabraknie pamięci RAM, jądro albo uruchamia swapowanie (co jest powolne), albo mechanizm OOM killer wybiera ofiarę i kończy jej działanie. Pierwsza opcja jest nieprzyjemna. W drugim przypadku dochodzi do utraty danych. Zapewnienie pamięci RAM z rezerwą nie jest tylko miłym dodatkiem — to właśnie zapobiega całkowitemu załamaniu się systemu pod obciążeniem.

Pamięć RAM w zależności od obciążenia

Serwery WWW i aplikacji

• Lekki stos LAMP lub LEMP: od 1 do 2 GB
• WordPress lub CMS z buforowaniem (np. Redis): od 2 do 4 GB
• E-commerce (Magento, WooCommerce): od 4 do 8 GB
• Aplikacje Node.js, Django lub Rails: od 2 do 6 GB

Warstwy buforowania, takie jak Redis lub Varnish, wymagają własnej pamięci RAM oprócz podstawowej pamięci przeznaczonej dla aplikacji. Procesy PHP-FPM, połączenia z bazami danych i serwery proxy odwrotne zużywają pamięć jednocześnie, więc istotną wartością jest szczytowa równoległość, a nie zużycie pamięci w stanie bezczynności.

Serwery baz danych (SQL i NoSQL)

• MySQL lub PostgreSQL (małe): od 4 do 8 GB
• MySQL lub PostgreSQL (duże lub o dużym natężeniu ruchu): od 16 do 64 GB
• MongoDB lub Redis (z naciskiem na pamięć): od 32 do 128 GB lub więcej
• Węzły Elasticsearch lub OpenSearch: od 32 do 128 GB na węzeł

Celem jest utrzymanie zestawu roboczego, indeksów i często używanych wierszy w pamięci RAM. Gdy jakakolwiek z tych danych trafi na dysk, opóźnienie wzrasta wielokrotnie, niezależnie od tego, jak szybki jest dysk SSD.

Hosty wirtualizacji (Proxmox, VMware, Hyper-V)

• Lekkie maszyny wirtualne z systemem Linux: od 2 do 4 GB na maszynę wirtualną
• Maszyny wirtualne z systemem Windows: od 8 do 12 GB na maszynę
• Panele hostingowe (cPanel, Plesk, DirectAdmin): od 4 do 8 GB na instancję
• Hosty kontenerów KVM lub LXC: od 32 do 128 GB lub więcej

Zawsze rezerwuj od 4 do 8 GB dla samego systemu operacyjnego hosta, oprócz przydziałów dla systemów-gości. Kontenery zużywają mniej pamięci RAM na obciążenie niż pełne maszyny wirtualne, ale skalują się inaczej, więc planuj z uwzględnieniem gęstości i rezerwy na skoki obciążenia, a nie rozmiaru poszczególnych kontenerów. Jeśli host korzysta z systemu plików ZFS, należy również uwzględnić pamięć ARC, która domyślnie zajmuje w tle nawet połowę pamięci RAM systemu i konkuruje o zasoby z przydziałami dla systemów-gości (nasz przewodnik po optymalizacji ARC w ZFS zawiera informacje na temat odpowiednich limitów dla obciążeń hiperwizora).

Kontenery i mikrousługi (Docker, Kubernetes)

• Proste stosy Docker (strona internetowa, aplikacja, baza danych): od 8 do 16 GB
• Węzły brzegowe Docker Swarm lub K3s: od 16 do 32 GB
• Węzły robocze Kubernetes: od 32 do 128 GB
• Uruchomienia CI/CD i agenci kompilacji (GitLab, Jenkins): od 8 do 32 GB na uruchomienie

Należy zwracać uwagę na wycieki pamięci w kontenerach działających przez dłuższy czas. Obciążenia oparte na JVM, takie jak Kafka i Elasticsearch, wymagają wyższych wartości bazowych, ponieważ sterta pamięci rozrasta się w dowolnym miejscu, co często przekracza oczekiwane wartości.

Wnioskowanie AI i ML

• Małe modele (kwantyzowany BERT, Llama 7B): od 16 do 32 GB
• Średnie modele (od 13B do 30B, kwantyzowane): od 64 do 128 GB
• Duże modele (40B+ lub niekwantyzowane modele średniej wielkości): od 128 do 512 GB lub więcej
• Inferencja wspierana przez GPU (Stable Diffusion, Whisper): od 32 do 128 GB w zależności od obciążenia

Kwantyzacja przenosi obciążenie pamięci z GPU na pamięć RAM procesora, więc specyfikacja systemu zmienia się znacząco w zależności od tego, czy obsługujesz fp16 na GPU, czy 4-bit na procesorze. Rozmiar partii i długość podpowiedzi również zwiększają te wartości. Nasz przewodnik po hostingu wnioskowania AI zawiera bardziej szczegółowe informacje na temat dopasowywania sprzętu do rozmiaru modelu.

Serwery gier

• Minecraft (wersja podstawowa): od 2 do 4 GB
• Minecraft (z modami): od 6 do 16 GB
• Rust, ARK lub 7 Days to Die: od 8 do 16 GB
• Węzły hostingowe obsługujące wiele instancji: od 32 do 64 GB

Specjalistyczne obciążenia

• Transkodowanie wideo (FFmpeg, Plex): od 16 do 64 GB
• Serwery kopii zapasowych lub migawek: od 8 do 16 GB, więcej w przypadku korzystania z silników deduplikacji
• Zapora sieciowa lub system wykrywania włamań (IDS) (pfSense, Suricata): od 2 do 8 GB, więcej w przypadku NetFlow lub pełnego rejestrowania pakietów

Nie polegaj na pamięci wymiany

Pamięć wymiany jest od 10 do 100 razy wolniejsza niż pamięć RAM. Służy ona jako zabezpieczenie, dzięki czemu jądro ma gdzie się przenieść w przypadku gwałtownego wzrostu zapotrzebowania na pamięć, a nie jako sposób na zwiększenie pamięci użytkowej. Jeśli serwer korzysta z pamięci wymiany przy normalnym obciążeniu, oznacza to po prostu, że ma za mało pamięci. Artykuł „Jak współdziałają pamięć wymiany w systemie Linux, mechanizm OOM killer i cgroups” szczegółowo omawia różne scenariusze awarii.

Jak dokładnie dobrać pojemność pamięci RAM

1. Należy mierzyć wartości szczytowe, a nie średnie. Należy skorzystać z htop, free -m, vmstat 1lub metryki Kubernetes, aby określić szczytowe zużycie w całym cyklu ruchu. Istotne są dzienne szczyty, tygodniowe partie oraz comiesięczne cykle rozliczeniowe.
2. Dodaj rezerwę na rozwój. Od 20% do 50% na skalowanie aplikacji. W przypadku baz danych skaluj pamięć zgodnie z rozmiarem zbioru danych, a nie częstotliwością żądań. W przypadku platform wielodostępnych oblicz zapotrzebowanie na pamięć dla każdego klienta i pomnóż wyniki.
3. Planuj z uwzględnieniem trybu awarii, który jesteś w stanie tolerować. Replika odczytu z niedoborem pamięci RAM działa gorzej. Główna instancja bazy danych z niedoborem pamięci RAM powoduje uszkodzenia zapytań i może doprowadzić do awarii aplikacji. Przeznacz pamięć RAM tam, gdzie zasięg skutków awarii jest największy.

Pamięć RAM to parametr, w przypadku którego jej niedobór szkodzi bardziej niż nadmiar. Dodanie pamięci nie przyspieszy aplikacji ograniczonej przez procesor, ale zbyt skromna konfiguracja niszczy stabilność. Określ wielkość na podstawie rzeczywistego monitorowania i sprawdzonych wartości szczytowych, a następnie pozostaw rezerwę.

FDC oferuje serwery dedykowane i VPS z konfiguracjami o dużej pojemności pamięci RAM oraz nieograniczoną przepustowością w wielu regionach.