Stabiele knooppunt-API met 512 MB RAM. Een maand later: PM2 start elke vier uur opnieuw op. We voegen max_memory_restart=800M toe – herstart de lus met veertig per minuut tijdens de middagpiek. Post-mortem: Map globale cache geïndexeerd op userId zonder uitzetting, geïntroduceerd met de functionaliteit voor “tijdelijke sessies” — langzaam lek, onzichtbaar in een test van tien minuten.
Node retourneert geheugen niet agressief naar het besturingssysteem - heapUsed kan mislukken na een garbage collector. Een lek is een trendgroei onder representatieve belasting, en geen piek na de implementatie. Elke nacht opnieuw opstarten verbergt het probleem totdat op een dag het interval niet langer voldoende is.
Controleer voordat u opnieuw opstart
Meet wat belangrijk is:
| Metrisch | Signaal |
|---|---|
process.memoryUsage().heapUsed | Trend na afvalinzameling |
| RSS | Het is de RSS die de OOM-moordenaar waarneemt |
| Gebeurtenislusvertraging | Lekkage + belasting = latentie van gebeurtenislus |
| Frequentie van GC-pauzes | Neemt toe als de stapel groeit |
Gemeenschappelijke hulpmiddelen:
- Prometheus met node_exporter en applicatiestatistieken
/metrics - PM2
pm2 monit,--max-memory-restartgekoppeld aan een waarschuwing als de herstartteller stijgt - APM (Datadog, enz.) om heap- en langzame query's met elkaar te correleren
Vuistregel: een masker geplande herstart – stel een RSS-waarschuwing in > basislijn × 1,5 gedurende één uur voordat u een nachtelijke cron toevoegt.
Opnieuw opstarten zonder grafiek betekent betalen voor de ambulance zonder diagnose.
Heap-diagnose
Procedure bij enscenering, daarna bij productie buiten de piek:
- Reproduceer een lange oplaadbeurt (k6 gedurende minimaal twee uur).
- Maak een heap-snapshot aan het begin en einde —
--inspectof--heapsnapshot-near-heap-limit(knooppunt 18+). - Vergelijk in Chrome DevTools (Vergelijking) — het aantal objecten neemt toe.
- Monteer de houders (sluiting, array, buffer) opnieuw.
Veelvoorkomende oorzaken van de web-API:
setIntervalnooit geannuleerd metclearIntervalsocket.ongedupliceerd zonderremoveListener- Globaal object
{ [reqId]: largeObject }nooit verwijderd - Logboekbibliotheek met contextreferenties
Hosting- en geheugenlimieten
In container of Kubernetes doodt de geheugenlimiet Node by SIGKILL zonder sierlijke afsluiting. Bepaal de limiet boven de maximale heap plus enige marge voor native code, of repareer het lek.
Op VPS verwisselt u huiden en vermindert vervolgens de prestaties - waarschuwing bij RSS, niet alleen bij CPU. Eén Node-proces: het lek heeft gevolgen voor de hele dienst. PM2-clustermodus corrigeert het lek niet; het vermenigvuldigt het over meerdere werknemers.
Vergelijk Node-geschikte VPS-aanbiedingen via de overzicht en de vergelijker. Voor implementatie kruist u met PM2 in productie.
PM2: herstart versus correctie
max_memory_restart: acceptabel tijdelijk met een prioritair onderzoeksticket.
Nachtelijke cron-herstart: aanvaardbaar als geen bekend lek (geheugen keert terug naar OS-eigenaardigheid) - geen vervanging voor correctie.
Combineer max_restarts en exp_backoff_restart_delay om herstartlussen te voorkomen die WebSockets halverwege de piek afsluiten.
De bovenkant: automatisch opnieuw opstarten is een ophopende schuld
Dit is wat PM2 verbergt als alles stabiel lijkt.
Teamcultuur: heap-snapshot voordat max_memory_restart wordt toegevoegd — of op zijn minst een gedateerd ticket voor de hoofdoorzaak.
Beslis en ga vooruit zonder blinde vlek
Voordat u een herstartcron toevoegt:
- Zevendaagse RSS-grafiek bij normaal verkeer: identificeer de trend, geen geïsoleerde pieken.
- Waarschuwing bij PM2-herstartteller — niet alleen HTTP-beschikbaarheid.
- Lange belastingstest tijdens fasering – minimaal twee uur om een langzaam lek aan het licht te brengen.
- Repareer de houders die in de momentopname zijn geïdentificeerd: kaart zonder TTL, luisteraars, timers.
- Verwijder de cron-herstart als de geheugencurve na correctie stabiliseert.
Raadpleeg PM2 deployment voor het monitoren van best practices, en de overzicht om een VPS te kiezen met voldoende RAM om een heap-snapshot buiten de piekuren vast te leggen.
Veelgestelde vragen
Hoe detecteer ik een Node.js-geheugenlek?
Observeer RSS of heapGebruikt gedurende meerdere uren of dagen bij stabiel verkeer. Als de curve stijgt zonder te dalen na het verzamelen van afval, is er sprake van een waarschijnlijk lek. Een piek en daarna een daling is normaal; een stijgend plateau is dat niet.
PM2 max_memory_restart is genoeg?
Dit is een noodoplossing: het wordt gerecycled vóór OOM, maar verliest de status, verbergt de hoofdoorzaak en kan in een lus terechtkomen. Koppel het aan een waarschuwing en een hoop onderzoek voordat u het probleem als opgelost beschouwt.
heapdump in productie?
Mogelijk buiten de piekuren met --heapsnapshot-near-heap-limit (Node 18+) of handmatig geactiveerde heapdump module. Analyseer in Chrome DevTools: vermijd middenpiek zonder de impact te meten.
Klassieke lekken op de Node-web-API?
Sluitingen met behoud van zoekopdrachtreferenties, gebeurtenislisteners niet verwijderd, kaartcache zonder levensduur, geaggregeerde buffers, vergeten timers - elk laat een langzaam stijgende RSS-curve achter.
Het monitoren van de geheugencurve kost minder dan een PM2 die in een lus opnieuw opstart op de dag dat het lek de cron inhaalt.