De câtă memorie RAM aveți nevoie cu adevărat pentru servere și VPS în 2025?

Dimensionarea memoriei RAM este o chestiune de calcul al sarcinii de lucru, nu un test de performanță. Dacă depășiți limita, veți plăti pentru capacitate neutilizată. Dacă rămâneți sub limita necesară, procesele dvs. vor fi oprite, baza de date va funcționa de pe disc în loc de memorie, sau containerele dvs. vor fi limitate. Acest ghid oferă intervale concrete de memorie RAM pentru sarcinile de lucru pe care le întâlnim cel mai des (găzduire web, baze de date, virtualizare, containere, inferență AI și servere de jocuri), precum și regulile de urmat atunci când se stabilește dimensiunea memoriei RAM pentru ceva ce nu se află pe listă.

Ce rol are memoria RAM într-un server

RAM-ul stochează tot ceea ce serverul procesează în mod activ. Memoria de proces pentru servere web, motoare de baze de date și daemoni care rulează în fundal. Cache-ul de pagini la nivel de sistem de operare și bufferele de I/O ale discului. Memoria de execuție pentru aplicații și containere. Și porțiunile de memorie alocate mașinilor virtuale sau sarcinilor de lucru ale containerelor.

Ceea ce diferențiază dimensionarea memoriei RAM de cea a procesorului este modul de eșec. Dacă rămâneți fără procesor, procesele încetinesc. Dacă rămâneți fără memorie RAM, fie kernelul recurge la swap (lent), fie „OOM killer” alege o victimă și o închide. Prima situație este neplăcută. În al doilea caz, se pierd date. Alocarea memoriei RAM cu o marjă de siguranță nu este doar un lux, ci este ceea ce împiedică prăbușirea sistemului sub presiunea încărcării.

RAM în funcție de volumul de lucru

Servere web și de aplicații

• Stivă LAMP sau LEMP ușoară: 1 până la 2 GB
• WordPress sau CMS cu cache (de ex. Redis): 2–4 GB
• Comerț electronic (Magento, WooCommerce): 4–8 GB
• Aplicații Node.js, Django sau Rails: 2 până la 6 GB

Straturile de cache precum Redis sau Varnish necesită memorie RAM proprie, pe lângă cea de bază a aplicației. Workerii PHP-FPM, conexiunile la baze de date și proxy-urile inverse consumă memorie simultan, astfel încât cifra care contează este paralelismul de vârf, nu amprenta în stare de inactivitate.

Servere de baze de date (SQL și NoSQL)

• MySQL sau PostgreSQL (de dimensiuni reduse): 4 până la 8 GB
• MySQL sau PostgreSQL (de dimensiuni mari sau cu trafic intens): 16 până la 64 GB
• MongoDB sau Redis (orientate către memoria internă): 32 până la 128 GB sau mai mult
• Noduri Elasticsearch sau OpenSearch: 32 până la 128 GB pe nod

Scopul este menținerea setului de lucru, a indexurilor și a rândurilor accesate frecvent în memoria RAM. Odată ce oricare dintre acestea ajunge pe disc, latența se multiplică cu ordine de mărime, indiferent de cât de rapid este SSD-ul.

Gazde de virtualizare (Proxmox, VMware, Hyper-V)

• Mașini virtuale Linux ușoare: 2 până la 4 GB pe mașină virtuală
• Mașini virtuale Windows: de la 8 la 12 GB pe mașină virtuală
• Panouri de găzduire (cPanel, Plesk, DirectAdmin): 4 până la 8 GB pe instanță
• Gazde de containere KVM sau LXC: 32 până la 128 GB sau mai mult

Rezervați întotdeauna între 4 și 8 GB pentru sistemul de operare gazdă, pe lângă alocările pentru mașinile virtuale oaspete. Containerele utilizează mai puțină memorie RAM pe sarcină de lucru decât mașinile virtuale complete, dar se scalează diferit, așa că planificați în funcție de densitate și de marja de creștere, mai degrabă decât de dimensiunea fiecărui container. Dacă gazda utilizează ZFS, luați în calcul și ARC, care, în mod implicit, va ocupa în mod silențios până la jumătate din memoria RAM a sistemului și va intra în competiție cu alocările pentru mașinile virtuale (ghidul nostru de optimizare a ARC pentru ZFS prezintă limitele corespunzătoare pentru sarcinile de lucru ale hipervizorului).

Containere și microservicii (Docker, Kubernetes)

• Stive Docker simple (web, aplicație, bază de date): 8 până la 16 GB
• Noduri de margine Docker Swarm sau K3s: 16 până la 32 GB
• Noduri de lucru Kubernetes: 32 până la 128 GB
• Runner-e CI/CD și agenți de compilare (GitLab, Jenkins): 8 până la 32 GB per runner

Fii atent la scurgerile de memorie în cazul containerelor care rulează pe termen lung. Sarcinile de lucru bazate pe JVM, precum Kafka și Elasticsearch, necesită valori de referință mai mari, deoarece heap-ul se va extinde cât de mult îi permiți, ceea ce înseamnă adesea mai mult decât te-ai aștepta.

Inferență AI și ML

• Modele mici (BERT cuantificat, Llama 7B): 16 până la 32 GB
• Modele medii (de la 13B la 30B, cuantificate): 64 până la 128 GB
• Modele mari (40B+ sau de gamă medie necuantificate): 128 până la 512 GB sau mai mult
• Inferență susținută de GPU (Stable Diffusion, Whisper): 32 până la 128 GB, în funcție de descărcare

Cuantificarea transferă presiunea asupra memoriei de la GPU la memoria RAM a CPU-ului, astfel încât specificațiile sistemului se modifică semnificativ în funcție de faptul dacă rulați fp16 pe GPU sau 4 biți pe CPU. Dimensiunea lotului și lungimea promptului contribuie, de asemenea, la creșterea acestor valori. Ghidul nostru privind găzduirea inferenței AI oferă informații mai detaliate despre potrivirea hardware-ului cu dimensiunea modelului.

Servere de jocuri

• Minecraft (versiune standard): 2 până la 4 GB
• Minecraft (modificat): 6 până la 16 GB
• Rust, ARK sau 7 Days to Die: 8 până la 16 GB
• Noduri de găzduire multi-instanță: 32 până la 64 GB

Sarcini de lucru specializate

• Transcodare video (FFmpeg, Plex): 16 până la 64 GB
• Servere de backup sau snapshot: 8 până la 16 GB, mai mult dacă rulează motoare de deduplicare
• Firewall sau IDS (pfSense, Suricata): 2 până la 8 GB, mai mult pentru NetFlow sau înregistrarea completă a pachetelor

Nu vă bazați pe memoria swap

Memoria swap este de 10 până la 100 de ori mai lentă decât memoria RAM. Ea există ca o plasă de siguranță, astfel încât kernel-ul să aibă unde să se refugieze atunci când presiunea asupra memoriei crește brusc, nu ca o modalitate de a extinde memoria utilizabilă. Dacă un server ajunge să folosească memoria swap în condiții normale de încărcare, înseamnă că nu are suficientă memorie alocată, punct. Articolul „Cum interacționează memoria swap din Linux, OOM killer și cgroups” prezintă în detaliu modurile de eșec.

Cum se calculează cu precizie dimensiunea memoriei RAM

1. Măsurați valorile de vârf, nu media. Utilizați htop, free -m, vmstat 1sau metricile Kubernetes pentru a identifica utilizarea de vârf pe parcursul unui ciclu complet de trafic. Vârfurile zilnice, loturile săptămânale și ciclurile lunare de facturare sunt toate importante.
2. Adăugați o marjă pentru creștere. Între 20% și 50% pentru scalarea aplicațiilor. Pentru bazele de date, scalați memoria în funcție de dimensiunea setului de date, nu de rata cererilor. Pentru platformele multi-tenant, calculați amprenta pe client și înmulțiți.
3. Planificați în funcție de modul de eșec pe care îl puteți tolera. O replică de citire care rămâne fără memorie RAM își reduce performanța. O bază de date primară care rămâne fără memorie RAM corupe interogările și poate duce la căderea aplicațiilor. Alocați memoria RAM acolo unde impactul este cel mai mare.

Memoria RAM este specificația pentru care insuficiența afectează mai mult decât excesul. Adăugarea de memorie nu va accelera o aplicație limitată de procesor, dar o configurație prea redusă distruge stabilitatea. Dimensiunea trebuie stabilită pe baza monitorizării reale și a vârfurilor testate, apoi lăsați un spațiu de rezervă.

FDC oferă servere dedicate și VPS cu configurații de memorie RAM mare și lățime de bandă nelimitată în mai multe regiuni.