A memória az az erőforrás, amely a leggyakrabban meghatározza egy szerver méretét: ez fogy el elsőként, és amikor elfogy, a szerver nem lelassul, hanem szolgáltatásokat állít le. Ez az útmutató megadja a számítási szabályt, azt, hogy egy alkalmazás egyes elemei mennyi memóriát használnak, tipikus profilokat, valamint a mérés módját egy már futó szerveren.
free -h parancs available oszlopát olvassa, ne a free oszlopot.Egy szerver nem „általában” fogyaszt memóriát: minden futó program lefoglal belőle egy részt, amíg fut. A számítás tehát az állandóan jelen lévő folyamatok listájából indul, majd hozzáadja a csúcsot és egy tartalékot:
Tervezendő memória = (rendszer + állandó szolgáltatások + az alkalmi feladatok csúcsa) × 1,25
Az alábbi nagyságrendek egy átlagos méretű, éles üzemben mért alkalmazásra érvényesek. Kiindulópontot adnak; az utolsó szó mindig a saját alkalmazásán végzett mérésé, amelyet lejjebb írunk le.
| Elem | Jellemző memória | Mitől változik |
|---|---|---|
| Nginx, Caddy (webszerver, proxy) | 10 és 50 MB között | Szinte állandó: a kapcsolatok száma alig számít. |
| PHP-FPM (WordPress, Laravel, Symfony) | Folyamatonként 40 és 80 MB között | A folyamatok száma, amelynek a pm.max_children szab felső határt: 10 folyamat 400 és 800 MB között foglal. |
| Node.js (API, Next.js, NestJS) | Folyamatonként 60 és 300 MB között | A folyamatok száma (cluster mód, PM2) és a heap mérete, amelynek a --max-old-space-size szab határt. |
| Python (Django, FastAPI, Flask) | Folyamatonként 80 és 200 MB között | A Gunicorn- vagy Uvicorn-workerek száma és a betöltött könyvtárak: a pandas vagy egy gépi tanulási modell több száz MB-ot tesz hozzá. |
| Java (Spring Boot) | Alkalmazásonként 300 MB és 1 GB között | A heap legnagyobb mérete: alapértelmezés szerint a JVM a számára látható memória negyedét foglalja le magának. |
| Go, Rust | 10 és 100 MB között | Az adatok, amelyeket az alkalmazás maga tart a memóriában. |
| PostgreSQL | A memória 25%-a a shared_buffers számára, plusz kapcsolatonként néhány MB | A gyakran lekérdezett adatok mennyisége, a kapcsolatok száma, a work_mem. |
| MySQL, MariaDB | innodb_buffer_pool_size, alapértelmezés szerint 128 MB | Egy csak az adatbázisnak szentelt szerveren ez a puffer gyakran a memória akár 80%-át is elfoglalja. |
| Redis | Az adatok mérete, plusz a struktúrái | Lemezre mentés közben a módosított lapok megkettőződnek: a legrosszabb esetben akár a dupla. |
| Elasticsearch, OpenSearch | Legalább 2 GB a heap számára | A heap a memória felénél kisebb marad: a maradék a fájlgyorsítótárat szolgálja. |
A JavaScript-alkalmazásoknál gyakran visszatér egy csúcs: a fordítás (build). Egy Next.js-, Nuxt- vagy Angular-projekten az npm run build önmagában gyakran 1 és 2 GB közötti memóriát igényel néhány percig, a már futó folyamatokon felül. Ha a szerveren fordít, erre a csúcsra kell méretezni; ha a saját gépén vagy a CI-rendszerében (folyamatos integráció) fordít, és csak az eredményt tölti fel, elkerüli.
Ugyanez az érvelés érvényes a Docker-konténerekre: minden konténer ugyanolyan folyamatok csoportja, mint a többi, és a Docker-démon hozzáadja a saját fogyasztását. A docker stats megmutatja, mennyit foglal mindegyik.
Ezek a profilok az előző elemeket adják össze, a csúccsal és a tartalékkal együtt. Átlagos méretű alkalmazást és egy induló projekt forgalmát feltételezik; egy nagy adatbázis vagy tartósan magas forgalom felfelé tolja az értéket.
| Ami a szerveren fut | Tervezendő memória |
|---|---|
| Statikus weboldal, proxy, kis bot vagy ütemezett szkript | 1 és 2 GB között |
| Egy WordPress-oldal MariaDB-vel és oldalgyorsítótárral | 2 GB |
| Egy WooCommerce-webáruház vagy több WordPress-oldal | 4 GB |
| Egy Node.js- vagy Python-API PostgreSQL-lel, az első felhasználókkal | 4 GB |
| Egy a szerveren fordított Next.js-alkalmazás, az API-ja és a PostgreSQL-adatbázisa | 6 és 8 GB között |
| Több konténerizált alkalmazás, előéles (staging) és éles környezet | 8 GB |
| Egy több tíz GB-os, intenzíven lekérdezett adatbázis | 16 GB vagy több |
| Egy 7 vagy 8 milliárd paraméteres nyelvi modell, a szerveren futtatva | 16 GB |
Az az alkalmazás, amely API-n keresztül hív egy MI-modellt (OpenAI, Anthropic, Mistral), ugyanúgy méretezendő, mint bármely webalkalmazás: a modell a szolgáltatójánál fut, az Ön szervere pedig a válaszára vár. A léptéket az változtatja meg, ha a modellt magán a szerveren futtatja.
Egy üzemelő szerveren a mérés lép a becslés helyébe. Három parancs megmutatja, hol tart:
free -h
ps aux --sort=-rss | head -n 15
vmstat 5 5free -h: az available oszlopot olvassa, azt a memóriát, amely új programok indítására valóban rendelkezésre áll. A free oszlop szinte mindig alacsony, és ez rendben van: a Linux a kihasználatlan memóriát fájlgyorsítótárral (buff/cache) tölti fel, amelyet azonnal visszaad, amint egy programnak szüksége van rá.ps aux --sort=-rss: a folyamatok az elfoglalt memória szerint rendezve (RSS oszlop, kilobájtban). Itt látszik, mennyit nyom egy-egy PHP- vagy Node.js-worker.vmstat 5 5: öt mérés ötmásodperces időközzel. Ha az si és az so oszlopban mérésről mérésre nullától eltérő értékek állnak, a szerver a swapot használja: kevés a memóriája.A nap legterheltebb időszakában mérjen, és az alkalmi feladatok alatt is: fordítás, mentés, importálás. A csúcs számít.
A memóriahiányos szerver nem fokozatosan lassul le. Amikor már nincs mit felszabadítani, a Linux-kernel elindítja az OOM killert (out of memory): kiválaszt egy folyamatot, általában azt, amelyik a legtöbb memóriát foglalja, és azonnal leállítja. Egy alkalmazásszerveren ez gyakran az adatbázis.
A tünetek: időnként megjelenő 502-es vagy 503-as hibák, egy látható ok nélkül újrainduló szolgáltatás, egy Killed üzenettel megszakadó fordítás. A naplók megerősítik:
journalctl -k | grep -i "out of memory"
systemctl status szolgaltatas-neveA systemctl status kimenetében a Failed with result 'oom-kill' sor memóriahiány miatt leállított szolgáltatást jelöl.
A swap, ha a szerver rendelkezik vele, kitolja ezt a pillanatot azzal, hogy a legkevésbé használt memóriát lemezre helyezi. Biztonsági háló, nem kapacitás: az a szerver, amely folyamatosan a swapra támaszkodik, többszörösen lassabban válaszol, még NVMe SSD-n is.
A megoldások, a legegyszerűbbtől a legtartósabbig: kevesebb alkalmazásfolyamat (pm.max_children, Gunicorn-workerek), fordítás a szerveren kívül, az adatbázis memóriájának korlátozása, majd váltás nagyobb méretre.
Nem a memória az egyetlen erőforrás: a processzor a számítási feladatoknál számít (fordítás, képfeldolgozás, MI-modell futtatása), a lemez az adatbázisnál és a fájloknál. Egy webalkalmazás méretét azonban szinte mindig a memória határozza meg.
A VPS Pro hat méretben érhető el, Intel Xeon processzorokon, ECC memóriával és tükrözött NVMe SSD-kkel, és bármikor nagyobb méretre válthat, újratelepítés nélkül. A Teljes körű támogatás a csomag része: írja le, mit fog futtatni a szervere, mi javasoljuk a méretet, majd minden kérdésnél diagnosztizálunk, és megmondjuk, mit tegyen, a rendszertől egészen az alkalmazása kódjáig.
Egy statikus weboldal, egy proxy vagy egy kis szkript 1 vagy 2 GB memóriával is beéri. Amint egy adatbázis és egy alkalmazás (PHP, Node.js, Python) osztozik a szerveren, számoljon 2 GB-tal egy WordPress-oldalhoz és 4 GB-tal egy PostgreSQL-t használó egyedi alkalmazáshoz.
2 GB egy MariaDB-t és oldalgyorsítótárat használó oldalhoz, 4 GB egy WooCommerce-webáruházhoz vagy több oldalhoz. Az első beállítás a PHP-FPM-folyamatok száma: mindegyik 40 és 80 MB között foglal.
Nem. A swap megakadályozza a hirtelen leállást, amikor megtelik a memória, de az a szerver, amely folyamatosan használja, többszörösen lassabban válaszol, még NVMe SSD-n is. Biztonsági háló; a méretet a memória alapján kell megválasztani.
Mert a Linux a kihasználatlan memóriát fájlgyorsítótárként használja. Ez a gyorsítótár felszabadul, amint egy programnak memóriára van szüksége. Az available oszlopot kell olvasni, amely a valóban rendelkezésre álló memóriát mutatja.
Magára a fordításra számoljon 1 vagy 2 GB-tal, a szerveren már futó folyamatokon felül. Ha a saját gépén vagy a CI-rendszerében fordít, és csak az eredményt telepíti, elkerüli ezt a csúcsot.
Simafri
Beszéljünk a weboldaláról
Meséljen néhány szóban a projektjéről: hamarosan jelentkezünk.
Köszönjük! Kérését elküldtük. Hamarosan válaszolunk.
Inkább e-mailben? Írjon nekünk ide: support@simafri.com.