Ile RAM potrzebuje VPS: zasada doboru dla każdego zastosowania

Zasada: zsumować to, co pozostaje w pamięci

Serwer nie zużywa pamięci „ogólnie”: każdy działający program zajmuje jej część tak długo, jak działa. Obliczenie zaczyna się więc od listy procesów obecnych na stałe, a następnie dodaje szczyt i zapas:

Potrzebna pamięć = (system + stałe usługi + szczyt zadań okresowych) × 1,25

• System: minimalna dystrybucja Linuksa (Debian, Ubuntu) zajmuje po uruchomieniu od 150 do 300 MB, łącznie z dostępem SSH i zapisem logów.
• Stałe usługi: serwer WWW, procesy aplikacji, baza danych, pamięć podręczna, kolejka zadań. Ich zużycie zależy od technologii i opisuje je następna sekcja.
• Szczyt: to, co dochodzi okresowo, czyli kompilacja aplikacji, kopia zapasowa, import, ciężkie zaplanowane zadanie. Serwer dobrany do średniej pada właśnie w takich chwilach.
• Zapas: 25 % ponad sumę, na wzrost danych i ruchu. Nie leży bezczynnie: Linux wykorzystuje wolną pamięć jako pamięć podręczną plików, co przyspiesza bazę danych.

Ile zużywa każdy element

Poniższe rzędy wielkości dotyczą aplikacji typowej wielkości, zmierzonej na produkcji. Są punktem wyjścia; ostatnie słowo zawsze należy do pomiaru własnej aplikacji, opisanego niżej.

W aplikacjach JavaScript często powraca jeden szczyt: kompilacja. npm run build w projekcie Next.js, Nuxt lub Angular potrzebuje zwykle sam od 1 do 2 GB przez kilka minut, ponad to, co już działa. Kompilacja na serwerze oznacza dobór rozmiaru do tego szczytu; kompilacja na własnym komputerze lub w ciągłej integracji (CI) i wgrywanie tylko wyniku pozwala go uniknąć.

To samo rozumowanie dotyczy kontenerów Docker: każdy kontener to zestaw zwykłych procesów, a demon Dockera dodaje własne zużycie. docker stats pokazuje, ile zajmuje każdy z nich.

Typowe profile

Te profile sumują powyższe elementy, łącznie ze szczytem i zapasem. Zakładają aplikację typowej wielkości i ruch z okresu uruchomienia; duża baza lub stały ruch przesuwają wynik w górę.

Aplikację, która wywołuje model AI przez API (OpenAI, Anthropic, Mistral), dobiera się jak każdą aplikację webową: model działa u swojego dostawcy, a Państwa serwer czeka na odpowiedź. Skalę zmienia dopiero uruchomienie modelu na samym serwerze.

Pomiar na działającym serwerze

Na działającym serwerze pomiar zastępuje szacunki. Trzy polecenia pokazują, jak wygląda sytuacja:

free -h
ps aux --sort=-rss | head -n 15
vmstat 5 5

• free -h: proszę czytać kolumnę available, czyli pamięć faktycznie dostępną do uruchomienia nowych programów. Kolumna free prawie zawsze pokazuje niską wartość i jest to normalne: Linux wypełnia nieużywaną pamięć pamięcią podręczną plików (buff/cache), którą oddaje, gdy tylko program jej potrzebuje.
• ps aux --sort=-rss: procesy uszeregowane według zajmowanej pamięci (kolumna RSS, w kilobajtach). Tu widać, ile waży każdy worker PHP lub Node.js.
• vmstat 5 5: pięć odczytów w odstępach pięciosekundowych. Wartości niezerowe w kolumnach si i so, odczyt po odczycie, oznaczają serwer, który korzysta z przestrzeni wymiany (swap): brakuje mu pamięci.

Proszę mierzyć w najbardziej obciążonej porze dnia oraz podczas zadań okresowych: kompilacji, kopii zapasowej, importu. Liczy się szczyt.

Gdy brakuje pamięci

Serwer, któremu kończy się pamięć, nie zwalnia stopniowo. Gdy nie ma już czego zwolnić, jądro Linuksa uruchamia OOM killer (out of memory): wybiera proces, zwykle ten, który zajmuje najwięcej pamięci, i natychmiast go zatrzymuje. Na serwerze aplikacji często jest to baza danych.

Objawy: sporadyczne błędy 502 lub 503, usługa, która restartuje się bez widocznego powodu, kompilacja przerwana komunikatem Killed. Potwierdzają to logi:

journalctl -k | grep -i "out of memory"
systemctl status nazwa-uslugi

W wyniku systemctl status wpis Failed with result 'oom-kill' oznacza usługę zatrzymaną z powodu braku pamięci.

Swap, jeśli serwer go ma, opóźnia ten moment, przenosząc na dysk najrzadziej używaną pamięć. To siatka bezpieczeństwa, a nie dodatkowa pojemność: serwer, który stale korzysta ze swapu, odpowiada kilkakrotnie wolniej, nawet na SSD NVMe.

Rozwiązania, od najprostszego do najtrwalszego: zmniejszyć liczbę procesów aplikacji (pm.max_children, workery Gunicorn), kompilować poza serwerem, ograniczyć pamięć bazy danych, a następnie przejść na większy rozmiar.

Wybór rozmiaru i plan na przyszłość

1. Proszę spisać, co będzie działać: serwer WWW, aplikacja i liczba jej procesów, baza danych, pamięć podręczna, zaplanowane zadania.
2. Proszę zsumować zużycie według tabeli elementów, dodać najcięższy szczyt (często kompilację), a potem 25 % zapasu.
3. Proszę wybrać rozmiar, który pokrywa tę sumę. Z dwóch sąsiednich rozmiarów wystarczy mniejszy, o ile przejście na większy odbywa się bez ponownej instalacji.
4. Proszę mierzyć po uruchomieniu, w szczycie dnia, a potem na każdym etapie wzrostu aplikacji.

Pamięć to nie jedyny zasób: procesor liczy się przy tym, co wykonuje obliczenia (kompilacja, przetwarzanie obrazów, uruchamianie modelu AI), a dysk przy bazie danych i plikach. W przypadku aplikacji webowej to jednak prawie zawsze pamięć wyznacza rozmiar.