Mennyi RAM-ra lesz valóban szükség a szerverekhez és a VPS-ekhez 2025-ben?

A RAM méretezésének alapja a terhelés számítása, nem pedig egy teljesítményteszt. Ha túl sokat költ, akkor a kihasználatlan kapacitásért is fizetnie kell. Ha pedig keveset szán rá, akkor a folyamatok leállnak, az adatbázis a memóriából helyett a lemezről szolgálja ki az adatokat, vagy a konténerek teljesítményét korlátozzák. Ez az útmutató konkrét RAM-tartományokat ad meg a leggyakrabban előforduló terhelésekhez (webtárhely, adatbázisok, virtualizáció, konténerek, mesterséges intelligencia-következtetés és játékkiszolgálók), valamint azokat a szabályokat, amelyeket akkor kell alkalmazni, ha olyan terhelés méretezéséről van szó, amely nem szerepel a listán.

Milyen szerepet játszik a RAM egy szerverben

A RAM tárolja mindazt, amin a szerver éppen aktívan dolgozik. A webszerverek, adatbázis-motorok és háttérdaemonok folyamatmemóriáját. Az operációs rendszer szintű oldalgyorsítótárat és a lemez I/O puffereket. Az alkalmazások és konténerek futási memóriáját. Valamint a virtuális gépeknek vagy konténeres munkaterheléseknek átadott memóriarészeket.

A RAM méretezését a CPU méretezésétől a hibaüzemmód különbözteti meg. Ha elfogy a CPU, a folyamatok lelassulnak. Ha elfogy a RAM, a kernel vagy swapol (lassú), vagy az OOM-killer kiválaszt egy áldozatot, és leállítja azt. Az első kellemetlen. A második esetben adatvesztés következik be. A RAM-nak tartalékkal történő ellátása nem csupán kívánatos, hanem elengedhetetlen ahhoz, hogy terhelés alatt ne omoljon össze a rendszer.

RAM a terhelés függvényében

Web- és alkalmazásszerverek

• Könnyű LAMP- vagy LEMP-stack: 1–2 GB
• WordPress vagy CMS gyorsítótárral (pl. Redis): 2–4 GB
• E-kereskedelem (Magento, WooCommerce): 4–8 GB
• Node.js, Django vagy Rails alkalmazások: 2–6 GB

A Redis vagy Varnish típusú gyorsítótár-rétegek az alkalmazás alapigényén felül saját RAM-ot igényelnek. A PHP-FPM munkaprogramok, az adatbázis-kapcsolatok és a fordított proxy-k mindegyike egyidejűleg fogyaszt memóriát, ezért a fontos adat a csúcs párhuzamosság, nem pedig az üresjárati memóriaigény.

Adatbázis-kiszolgálók (SQL és NoSQL)

• MySQL vagy PostgreSQL (kicsi): 4–8 GB
• MySQL vagy PostgreSQL (nagy vagy nagy forgalmú): 16–64 GB
• MongoDB vagy Redis (memóriaközpontú): 32–128 GB vagy több
• Elasticsearch vagy OpenSearch csomópontok: csomópontonként 32–128 GB

A cél az, hogy a munkakészlet, az indexek és a gyakran hozzáférhető sorok a RAM-ban maradjanak. Amint ezek közül bármelyik a lemezre kerül, a késleltetés nagyságrendekkel megnő, függetlenül attól, hogy milyen gyors az SSD.

Virtualizációs gazdagépek (Proxmox, VMware, Hyper-V)

• Könnyű Linux virtuális gépek: virtuális gépenként 2–4 GB
• Windows virtuális gépek: 8–12 GB virtuális gépenként
• Tárhelykezelő panelek (cPanel, Plesk, DirectAdmin): 4–8 GB példányonként
• KVM- vagy LXC-konténergazdagépek: 32–128 GB vagy több

A vendégrendszerek számára kiosztott memória mellett mindig tartalékoljon 4–8 GB-ot magának a gazda operációs rendszernek. A konténerek munkaterhelésenként kevesebb RAM-ot használnak, mint a teljes virtuális gépek, de másképp skálázódnak, ezért inkább a sűrűséget és a csúcsigényt vegye figyelembe, mint az egyes konténerek méretét. Ha a gazdagép ZFS-t használ, vegye figyelembe az ARC-t is, amely alapértelmezés szerint észrevétlenül elfoglalja a rendszer RAM-jának akár a felét is, és verseng a vendégallokációkkal (ZFS ARC-beállítási útmutatónk bemutatja a hipervizor-terhelésekhez megfelelő felső határokat).

Konténerek és mikroszolgáltatások (Docker, Kubernetes)

• Egyszerű Docker-stackek (web, alkalmazás, adatbázis): 8–16 GB
• Docker Swarm vagy K3s peremcsomópontok: 16–32 GB
• Kubernetes munkacsomópontok: 32–128 GB
• CI/CD futtatók és build-ügynökök (GitLab, Jenkins): futtatónként 8–32 GB

Figyeljen a hosszú ideig futó konténerek memóriaszivárgásaira. A JVM-alapú terhelések, mint például a Kafka és az Elasticsearch, magasabb alapértékeket igényelnek, mivel a heap ott telepedik le, ahol hagyja, ami gyakran magasabb, mint amire számított.

AI és ML következtetés

• Kis modellek (kvantált BERT, Llama 7B): 16–32 GB
• Közepes méretű modellek (13B–30B, kvantált): 64–128 GB
• Nagy modellek (40B+ vagy nem kvantált közepes méretűek): 128–512 GB vagy több
• GPU-támogatott következtetés (Stable Diffusion, Whisper): 32–128 GB, az offloadtól függően

A kvantálás a memóriaterhelést a GPU-ról a CPU RAM-jára helyezi át, így a rendszer specifikációi jelentősen változnak attól függően, hogy fp16-ot futtat-e a GPU-n, vagy 4-biteset a CPU-n. A kötegméret és a prompt hossza szintén növeli az igényeket. Az AI-következtetés-tárhelyről szóló útmutatónk részletesebben tárgyalja a hardver és a modellméret összehangolását.

Játékkiszolgálók

• Minecraft (alapváltozat): 2–4 GB
• Minecraft (módosított): 6–16 GB
• Rust, ARK vagy 7 Days to Die: 8–16 GB
• Többinstanciás tárhelycsomópontok: 32–64 GB

Speciális munkaterhelések

• Videó átkódolás (FFmpeg, Plex): 16–64 GB
• Biztonsági mentési vagy pillanatfelvétel-kiszolgálók: 8–16 GB, duplikációmentesítő motorok futtatása esetén ennél több
• Tűzfal vagy IDS (pfSense, Suricata): 2–8 GB, több, ha NetFlow vagy teljes csomagnaplózás is fut

Ne támaszkodjon a swap memóriára

A swap 10–100-szor lassabb, mint a RAM. Biztonsági hálóként szolgál, hogy a kernelnak legyen hova mennie, ha a memóriaigény hirtelen megnő, nem pedig a használható memória bővítésére. Ha egy szerver normál terhelés mellett is a swap-ot használja, akkor egyszerűen nincs elegendő memóriája, pont. A „Hogyan működik együtt a Linux swap, az OOM killer és a cgroups?” című cikk részletesen bemutatja a lehetséges hibamódokat.

Hogyan lehet pontosan meghatározni a RAM méretét

1. A csúcsértéket mérje, ne az átlagot. Használja htop, free -m, vmstat 1vagy a Kubernetes-mutatóit, hogy meghatározza a teljes forgalmi cikluson belüli csúcsfelhasználást. A napi csúcsok, a heti kötegek és a havi számlázási ciklusok egyaránt fontosak.
2. Hagyjon tartalékot a növekedésre. 20–50%-ot az alkalmazások méretezéséhez. Adatbázisok esetében az adatállomány méretének megfelelően méretezze a memóriát, ne a lekérdezések gyakorisága alapján. Többfelhasználós platformoknál számítsa ki az egy ügyfélre jutó memóriaigényt, majd szorozza meg.
3. A tervezés során vegye figyelembe azt a hibahelyzetet, amelyet még el tud viselni. Ha egy olvasási replikának elfogy a RAM-ja, a teljesítmény romlik. Ha egy adatbázis-primernek elfogy a RAM-ja, az megrongálja a lekérdezéseket, és magával rántja az alkalmazásokat is. A RAM-ot ott használja fel, ahol a hatáskör a legnagyobb.

A RAM az a specifikáció, ahol a hiány nagyobb kárt okoz, mint a túlzott kapacitás. A memória bővítése nem gyorsítja fel a CPU-korlátozott alkalmazásokat, de a túl szűkös konfiguráció rontja a stabilitást. A méretet a valós monitorozás és a tesztelt csúcsértékek alapján határozza meg, majd hagyjon tartalékot.

Az FDC nagy RAM-kapacitású konfigurációjú dedikált szervereket és VPS-eket kínál, korlátlan sávszélességgel több régióban is.