module.exports = {
apps: [{
name: 'api-productie',
script: './dist/index.js',
instances: 'max',
exec_mode: 'cluster',
wait_ready: true,
listen_timeout: 10000,
kill_timeout: 8000,
max_memory_restart: '800M',
env: {
NODE_ENV: 'production'
},
error_file: './logs/err.log',
out_file: './logs/out.log',
merge_logs: true,
log_date_format: 'YYYY-MM-DD HH:mm:ss'
}]
};Am văzut prea multe proiecte de Node.js în producție pornite cu un simplu pm2 start index.js. E ok pentru un MVP rapid, dar când ai trafic real te lovești repede de downtime la deploy-uri sau de servere blocate din cauza memoriei. Un ecosystem.config.js bine pus la punct îți rezolvă problemele astea fără să complici infrastructura cu Docker sau Kubernetes.
Trecem direct prin setările care contează și pe care le-am testat pe pielea mea la proiecte cu peste 15.000 de utilizatori activi.
Cluster Mode și deploy fără downtime
Dacă rulezi în fork_mode (cel implicit), când dai pm2 restart app aplicația ta moare complet pentru câteva secunde până se reîncarcă Node.js și se refac conexiunile la baza de date. Utilizatorii vor vedea erori 502 Bad Gateway. Nu e deloc profi.
Soluția este cluster_mode. Acesta pornește câte o instanță a aplicației pentru fiecare nucleu CPU disponibil. Când faci deploy, folosești pm2 reload app în loc de restart. PM2 va reporni instanțele una câte una (graceful reload), menținând serviciul activ 100% din timp pentru utilizatori.
Trade-off sincer: Modul cluster funcționează de minune doar dacă aplicația ta este complet stateless. Dacă salvezi sesiuni în memoria procesului sau folosești WebSocket-uri fără un adaptor de Redis, clienții vor fi deconectați sau vor pierde sesiunea când sunt distribuiți la alt worker. Dacă ai state local și nu ai timp să refaci arhitectura, rămâi pe single instance și acceptă cele 2 secunde de downtime la deploy.
Prevenirea OOM (Out of Memory)
Node.js are un garbage collector destul de leneș, iar scurgerile de memorie sunt la ordinea zilei în ecosistemul npm. Am pățit la un proiect ca un memory leak subtil de la o librărie de manipulare PDF să consume 4GB de RAM în doar câteva ore, blocând complet VPS-ul.
Prin setarea max_memory_restart: '800M', PM2 monitorizează constant consumul de RAM. Când worker-ul sare de limita setată, PM2 îi dă un restart curat. În modul cluster, ceilalți workeri preiau traficul fără probleme, deci utilizatorul final nu simte nimic. De ce 800M și nu 2G? Pentru că pe mașini virtuale medii, vrei să prinzi leak-ul înainte să se declanșeze OOM Killer-ul din Linux, care adesea omoară baza de date sau chiar procesul principal PM2.
Graceful Shutdown: cum închizi conexiunile curat
Când PM2 vrea să oprească un worker (la reload sau restart), îi trimite semnalul SIGINT. Implicit, PM2 așteaptă doar 1600ms înainte să trimită SIGKILL (forțat). Dacă ai query-uri grele în rulare sau upload-uri de fișiere mari, le vei tăia brutal.
Mărește această limită folosind kill_timeout: 8000 (8 secunde). În codul tău de Node, trebuie să asculți după acest semnal și să închizi serverul HTTP și conexiunile la baza de date înainte ca procesul să se termine de tot.
Ce facem cu logurile uriașe?
PM2 scrie tot ce prinzi în console.log în fișiere text simple. Dacă ai trafic serios, te poți trezi cu discul plin în câteva luni. Am avut un caz în care un client m-a sunat duminica pentru că baza de date nu mai putea scrie nimic pe disc. Logul de PM2 ajunsese la 52GB.
Configurația de mai jos trimite logurile în fișiere separate și le combină inteligent. Totuși, ca să nu ai surprize, trebuie să instalezi modulul de rotație rulând în terminal: pm2 install pm2-logrotate. Acesta va tăia fișierele automat când ajung la 10MB și va păstra doar ultimele 30 de arhive.
Voi cum gestionați rularea în producție? Mergeți pe PM2 pe VPS-uri clasice sau ați trecut deja totul în containere Docker?