module.exports = {
apps: [{
name: 'api-service',
script: './dist/server.js',
instances: 'max',
exec_mode: 'cluster',
max_memory_restart: '600M',
kill_timeout: 5000,
wait_ready: true,
listen_timeout: 8000,
env_production: {
NODE_ENV: 'production',
PORT: 3000
}
}]
};Dă-i încolo de pm2 start app.js --name api. Când ajungi în producție, ești la un pas de dezastru dacă nu folosești un fișier ecosystem.config.js bine structurat. Am văzut zeci de proiecte picate la primul spike de trafic sau rămase fără spațiu pe disk din cauza logurilor scapate de sub control.
De la fork la cluster fără downtime
Cluster mode e aur curat dacă ai o mașină cu mai multe nuclee vCPU. PM2 folosește modulul cluster din Node.js și ridică câte o instanță per nucleu, împărțind același port. Câștigul? Scalare orizontală pe o singură mașină, fără Docker sau Kubernetes.
Secretul pentru zero-downtime deploy este graceful reload. Când rulezi pm2 reload ecosystem.config.js, PM2 nu oprește toate procesele deodată. Oprește primul worker, așteaptă ca noul worker să fie pregătit să preia trafic, apoi trece la următorul.
Tranzacția vine însă cu un trade-off clar: cluster mode e excelent pentru aplicații stateless, dar e un dezastru dacă salvezi sesiuni în memorie sau dacă ai joburi de tip Cron rulate direct în cod. Dacă ai un setInterval care trimite e-mailuri, se va executa pe fiecare worker în parte.
Ce facem cu Memory Leaks? Auto-restart la OOM
Oricât de atenți suntem la code review, memory leak-urile apar. Am pățit asta pe un API Express cu 12k request-uri pe minut, unde o librărie terță de generat PDF-uri reținea buffere în RAM. Până să găsim bug-ul exact, salvarea a fost opțiunea max_memory_restart.
Configurată la 600M, PM2 va reporni automat instanța când depășește acest prag, fără ca utilizatorii să vadă un 502 Bad Gateway (celelalte instanțe din cluster preiau traficul). Setarea kill_timeout este critică aici: oferă aplicației tale câteva secunde să închidă conexiunile la baza de date și să finalizeze request-urile pe rol înainte de primirea semnalului SIGKILL.
Capcana logurilor pe disk
Implicit, PM2 scrie tot ce e în stdout și stderr în ~/.pm2/logs/. La un serviciu cu trafic mare, în două luni te trezești cu fișiere de 40-50GB și un server care refuză să mai pornească pentru că e disk-ul plin. PM2 nativ nu știe să rotească logurile.
Trebuie să instalezi modulul de log rotate din terminal: pm2 install pm2-logrotate. Odată pus, acesta preia automat gestionarea logurilor, comprimându-le și ștergându-le pe cele vechi conform politicilor tale.
Voi cum gestionați Node.js în producție la proiectele medii? Folosiți PM2 în continuare sau ați trecut direct pe Docker containerizat cu Traefik/Nginx în față?