Sentry-javascript: withScope-Speicherleck, sehr offensichtlich bei Verwendung von scope.setTag in @sentry/node

Erstellt am 12. Aug. 2019  ·  3Kommentare  ·  Quelle: getsentry/sentry-javascript

Paket + Version

  • [ ] @sentry/browser
  • [x] @sentry/node
  • [ ] raven-js
  • [ ] raven-node _(Rabe für Knoten)_
  • [ ] Sonstiges:

Ausführung:

5.5.0

Beschreibung

Erstellen eines neuen Problems seit #1762 geschlossen wurde.
Es gibt ein kleines Speicherleck in @sentry/node. Der Aufruf von setTag mit einigen langen Strings macht es viel größer.
Dies ist identifizierbar, weil es nicht nur ein Speicherleck ist, sondern laut meinen DO-Droplet-Metriken einen dauerhaften Anstieg der CPU-Auslastung und der öffentlichen Bandbreite verursacht, der nur durch einen Neustart des Servers behoben werden kann.
Das Bild zeigt, was passiert, wenn ich setTag hinzugefügt habe (11. Juli) und wenn ich es entfernt habe (9. August).
System memory (1)

Needs Reproduction

Hilfreichster Kommentar

@kamilogorek der beleidigende Code ist hier: https://github.com/ParabolInc/action/blob/0bde4b002aa3d53fc00f1febcb39185079d827f2/packages/server/utils/sendToSentry.ts#L28 -L35

So wie es aussieht, wird das Zielfernrohr nicht GC'd.

Es mag unbeliebt sein, aber alles, was ich wirklich will, ist ein sauberer API-Aufruf, der eine Ausnahme und Variablen akzeptiert. zB Sentry.captureExpection(error, {tags: {foo: 1}}) . das würde die Bereiche und die damit verbundenen Speicherlecks beseitigen.

Alle 3 Kommentare

Können Sie dafür einen Repro-Fall zur Verfügung stellen? setTag mit mehreren gleichzeitigen Anforderungen wird sicherlich den Speicherbedarf erhöhen, aber sobald ein Bereich GC-bewertet ist, sollte der Speicher auf die Grundlinie sinken.

@kamilogorek der beleidigende Code ist hier: https://github.com/ParabolInc/action/blob/0bde4b002aa3d53fc00f1febcb39185079d827f2/packages/server/utils/sendToSentry.ts#L28 -L35

So wie es aussieht, wird das Zielfernrohr nicht GC'd.

Es mag unbeliebt sein, aber alles, was ich wirklich will, ist ein sauberer API-Aufruf, der eine Ausnahme und Variablen akzeptiert. zB Sentry.captureExpection(error, {tags: {foo: 1}}) . das würde die Bereiche und die damit verbundenen Speicherlecks beseitigen.

withScope am Ende seines Lebenszyklus eine popScope Operation aus, die den Layer aus dem internen Array entfernt, daher gibt es keinen starken Verweis darauf - GC kümmert sich automatisch darum.
fwfw können Sie Ihren Anruf ändern auf:

Sentry.withScope((scope) => {
  scope.setUser(user)
  scope.setTags(tags)
  Sentry.captureException(error)
});
War diese Seite hilfreich?
0 / 5 - 0 Bewertungen