module.exports = {
apps: [{
name: "api-prod",
script: "./dist/server.js",
instances: "max",
exec_mode: "cluster",
autorestart: true,
watch: false,
max_memory_restart: "800M",
error_file: "./logs/err.log",
out_file: "./logs/out.log",
merge_logs: true,
listen_timeout: 8000,
kill_timeout: 5000,
env: {
NODE_ENV: "production"
}
}]
};Am văzut prea multe proiecte de Node.js aruncate în producție cu un simplu pm2 start server.js. E ok pentru un MVP obosit, dar când ai trafic real, te lovești rapid de downtime. Am pățit asta acum vreo trei ani la un API de livrări cu vreo 15k utilizatori activi zilnic, unde un memory leak ascuns ne umplea RAM-ul în câteva ore și bloca tot serverul.
Salvarea a fost trecerea la un fișier de configurare dedicat, ecosystem.config.js. Nu e doar zahăr sintactic, ci îți dă control complet peste procese, loguri și comportamentul la crash.
Cluster Mode și Graceful Reload fără downtime
Dacă rulezi Node în mod single-thread, lași bani pe masă și CPU-ul degeaba. Cu instances: "max" și exec_mode: "cluster", PM2 îți pornește câte o instanță pentru fiecare nucleu CPU disponibil. Traficul este distribuit automat prin round-robin. În loc să rulezi un singur proces care se sufocă la prima operațiune sincronă mai grea, ai o armată de procese gata de treabă.
Dar magia adevărată apare când faci deploy. În loc de pm2 restart, care oprește tot și pornește din nou generând un downtime de câteva secunde, folosește pm2 reload. Reload-ul oprește și repornește instanțele pe rând, una câte una. Ca să meargă perfect, în codul tău de Node trebuie să asculți de semnalul SIGINT și să închizi conexiunile la baza de date înainte ca procesul să moară. Altfel, PM2 va forța oprirea după un timeout de câteva secunde, iar conexiunile clienților activi vor fi tăiate brutal.
Trade-off-ul aici? Dacă folosești sesiuni stocate în memoria aplicației sau conexiuni de WebSocket simple, cluster mode le va rupe. Pentru WebSockets ai nevoie de un adaptor de Redis, altfel utilizatorul va fi deconectat când cererea lui nimerește pe alt thread.
Auto-restart la OOM (Out of Memory)
Node.js are prostul obicei să mănânce memorie dacă ai un leak mic pe undeva. Decât să te sune clientul la 3 dimineața că API-ul dă erori 502, mai bine pui o limită de siguranță direct din configurare.
Cu proprietatea max_memory_restart: "800M", PM2 monitorizează constant consumul de RAM. Când thread-ul trece de pragul de 800MB (ajustează valoarea în funcție de serverul tău), PM2 îi dă un kill elegant și îl repornește în fundal. Nu rezolvă bug-ul de memorie, tot va trebui să faci profiling cu Chrome DevTools mai târziu, dar măcar îți cumpără timp să dormi liniștit noaptea.
Coșmarul logurilor care umplu discul
Implicit, PM2 scrie toate logurile într-un singur fișier uriaș în folderul local al utilizatorului. Am avut un caz în care un server de producție a intrat în crash-loop din cauză că discul de 40GB era plin ochi de loguri de eroare nestructurate. Sistemul de operare pur și simplu nu mai avea unde să scrie fișiere temporare.
În configurația de mai jos e bine să separi out_file de error_file ca să poți debuga mai ușor. Dar cel mai important pas: instalează modulul de rotație direct pe server. Rulezi în terminal pm2 install pm2-logrotate și el va tăia fișierele când ating o dimensiune (de exemplu, 10MB). Fără asta, e doar o chestiune de timp până când serverul tău se va bloca complet.
Voi cum gestionați procesele de Node în producție? Mergeți pe PM2-ul clasic sau ați trecut complet pe Docker și Kubernetes pentru orchestrare?