Koliko RAM-a potrebuje VPS: pravilo za vsako vrsto rabe

Pravilo: seštejte, kar ostaja v pomnilniku

Strežnik ne porablja pomnilnika „na splošno“: vsak program, ki teče, zase zadrži del pomnilnika, dokler teče. Izračun se zato začne s seznamom procesov, ki so stalno prisotni, nato pa doda konico in rezervo:

Potreben pomnilnik = (sistem + stalne storitve + konica občasnih opravil) × 1,25

• Sistem: minimalna distribucija Linuxa (Debian, Ubuntu) po zagonu zasede od 150 do 300 MB, skupaj z dostopom SSH in beleženjem dnevnikov.
• Stalne storitve: spletni strežnik, procesi aplikacije, podatkovna zbirka, predpomnilnik, čakalna vrsta opravil. Njihova poraba je odvisna od tehnologije, podrobno opisane v naslednjem razdelku.
• Konica: kar se občasno doda, na primer prevajanje aplikacije, varnostno kopiranje, uvoz ali zahtevno načrtovano opravilo. Strežnik, dimenzioniran na povprečje, odpove prav v teh trenutkih.
• Rezerva: 25 % nad skupno vsoto, za rast podatkov in prometa. Ne miruje: Linux prosti pomnilnik uporablja kot predpomnilnik datotek, kar pospeši podatkovno zbirko.

Koliko porabi vsak gradnik

Spodnji redi velikosti veljajo za aplikacijo običajne velikosti, izmerjeno v produkciji. So izhodišče; zadnjo besedo ima vedno meritev na vaši lastni aplikaciji, opisana v nadaljevanju.

Pri aplikacijah v JavaScriptu se pogosto ponovi ena konica: prevajanje (build). npm run build na projektu Next.js, Nuxt ali Angular samo zase pogosto zahteva od 1 do 2 GB, za nekaj minut, poleg vsega, kar že teče. Prevajati na strežniku pomeni dimenzionirati za to konico; prevajati na svojem računalniku ali v sistemu za stalno integracijo in na strežnik naložiti samo rezultat pomeni, da se ji izognete.

Enak razmislek velja za vsebnike Docker: vsak vsebnik je skupina procesov kot vsi drugi, demon Docker pa doda svojo porabo. docker stats prikaže, koliko zasede vsak.

Značilni profili

Ti profili seštejejo zgornje gradnike, vključno s konico in rezervo. Predpostavljajo aplikacijo običajne velikosti in promet ob zagonu; obsežna podatkovna zbirka ali stalen promet številko premakneta navzgor.

Aplikacija, ki model umetne inteligence kliče prek API-ja (OpenAI, Anthropic, Mistral), se dimenzionira kot vsaka spletna aplikacija: model teče pri svojem ponudniku, vaš strežnik pa čaka na odgovor. Merilo spremeni šele izvajanje modela na samem strežniku.

Merjenje na strežniku, ki že teče

Na strežniku v produkciji meritev nadomesti oceno. Trije ukazi povedo, kje ste:

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

• free -h: preberite stolpec available, pomnilnik, ki je dejansko na voljo za zagon novih programov. Stolpec free je skoraj vedno nizek, in to je normalno: Linux neuporabljeni pomnilnik zapolni s predpomnilnikom datotek (buff/cache), ki ga sprosti, takoj ko ga program potrebuje.
• ps aux --sort=-rss: procesi, razvrščeni po zasedenem pomnilniku (stolpec RSS, v kilobajtih). Tu vidite, koliko tehta vsak delovni proces PHP ali Node.js.
• vmstat 5 5: pet meritev v razmiku petih sekund. Neničelne vrednosti v stolpcih si in so, meritev za meritvijo, kažejo na strežnik, ki izmenjuje podatke s swapom: pomnilnika mu primanjkuje.

Merite v najbolj obremenjenem delu dneva in med občasnimi opravili: prevajanje, varnostno kopiranje, uvoz. Šteje konica.

Ko pomnilnika zmanjka

Strežnik, ki mu zmanjka pomnilnika, se ne upočasnjuje postopoma. Ko ni več ničesar, kar bi lahko sprostil, jedro Linuxa sproži OOM killer (out of memory): izbere proces, praviloma tisti, ki zaseda največ pomnilnika, in ga v trenutku ustavi. Na aplikacijskem strežniku je to pogosto podatkovna zbirka.

Simptomi: občasne napake 502 ali 503, storitev, ki se brez vidnega razloga znova zažene, prevajanje, ki se prekine z izpisom Killed. Dnevniki to potrdijo:

journalctl -k | grep -i "out of memory"
systemctl status ime-storitve

V izpisu ukaza systemctl status navedba Failed with result 'oom-kill' označuje storitev, ustavljeno zaradi pomanjkanja pomnilnika.

Swap, kadar ga strežnik ima, ta trenutek odloži, tako da najmanj uporabljeni pomnilnik premakne na disk. Je varnostna mreža, ne zmogljivost: strežnik, ki se nenehno opira na swap, odgovarja nekajkrat počasneje, tudi na NVMe SSD.

Rešitve, od najpreprostejše do najtrajnejše: zmanjšajte število procesov aplikacije (pm.max_children, delovni procesi Gunicorn), prevajajte zunaj strežnika, omejite pomnilnik podatkovne zbirke, nato preidite na večjo velikost.

Izbira velikosti in načrtovanje naprej

1. Naštejte, kaj bo teklo: spletni strežnik, aplikacija in število njenih procesov, podatkovna zbirka, predpomnilnik, načrtovana opravila.
2. Seštejte s pomočjo preglednice gradnikov, dodajte najzahtevnejšo konico (pogosto prevajanje), nato 25 % rezerve.
3. Izberite velikost, ki to vsoto pokrije. Med dvema sosednjima velikostma zadošča manjša, če je prehod na večjo mogoč brez ponovne namestitve.
4. Merite po zagonu v produkciji, ob dnevni konici, nato ob vsakem koraku rasti aplikacije.

Pomnilnik ni edini vir: procesor šteje za vse, kar računa (prevajanje, obdelava slik, izvajanje modela umetne inteligence), disk pa za podatkovno zbirko in datoteke. Pri spletni aplikaciji pa velikost skoraj vedno določi prav pomnilnik.