node.js Prozessspeicherfehler

FATAL ERROR: CALL_AND_RETRY_2 Allocation Failed - process out of memory

Ich sehe diesen Fehler und bin mir nicht sicher, woher er kommt. Das Projekt, an dem ich gerade arbeite, hat diesen grundlegenden Workflow:

1. Empfange XML-Post von einer anderen Quelle
2. Parsen Sie das XML mit xml2js
3. Extrahieren Sie die erforderlichen Informationen aus dem neu erstellten JSON-Objekt und erstellen Sie ein neues Objekt.
4. Senden Sie dieses Objekt an verbundene Clients (mit socket.io)

Knotenmodule werden verwendet:

• xml2js
• socket.io
• Choreograph
• mysql

Wenn ich ein XML-Paket erhalte, schreibe ich es als erstes in eine log.txt-Datei, falls etwas später überprüft werden muss. Ich zuerst fs.readFile , um den aktuellen Inhalt zu erhalten, dann schreibe den neuen Inhalt + den alten. Die log.txt Datei war wahrscheinlich um 2400KB um den letzten Absturz, aber nach dem Neustart des Servers funktioniert es wieder gut und ich glaube nicht, dass dies das Problem ist.

Ich sehe kein Paket im Log direkt vor dem Absturz, also bin ich mir nicht sicher, was den Absturz verursacht hat ... Es sind keine neuen Clients verbunden, keine Nachrichten wurden gesendet ... nichts wurde geparst.

Bearbeiten

Da der Knoten ständig ausgeführt wird, sollte ich delete <object> verwenden, nachdem jedes Objekt, das ich verwende, seinen Zweck erfüllt, wie zum Beispiel var now = new Date() , mit dem ich Dinge vergleichen kann, die in der Vergangenheit passieren. Oder Ergebnisobjekt aus Schritt 3, nachdem ich es an den Rückruf übergeben habe?

Bearbeiten 2

Ich behalte ein Master-Objekt für den Fall, dass ein neuer Client eine Verbindung herstellt, sie müssen vergangene Nachrichten sehen, Objekte werden jedoch gelöscht, sie bleiben nicht für die Lebensdauer des Servers, nur bis sie auf der Client-Seite abgeschlossen sind. Momentan mache ich so etwas.

Bearbeiten 3

Als weiteren Schritt zur Fehlerbehebung habe ich das process.memoryUsage().heapUsed vor dem Start des Parsers bei parser.on('end', function() {..}); abgelegt und mehrere xml Pakete geparst. Der höchste verwendete Heap war während des Tests etwa 10-12 MB, obwohl das Programm unter normalen Bedingungen bei etwa 4-5 MB liegt. Ich denke nicht, dass dies ein Deal Breaker ist, aber kann helfen, das Problem zu finden.