2017-12-08 2 views
0

Während Speicher Profiling meiner Anwendung (.NET Dienst über Service-Fabric gehostet) bemerkte ich EventHandler<UnobservedTaskExceptionEventArgs> hat 24 Instanzen jede hat Größe 1880B, aber inklusive Größe - die ich nehme, ist das Objekt + alle Referenzen um 1,2GB.Speicherauslastung für EventHandler <UnobservedTaskExceptionEventArgs>

Ich nehme an, das ist irgendwie im Zusammenhang mit Ausnahmen in unbeaufsichtigten Aufgaben. Kann das ein Fehler sein oder ist es ein Ablenkungsmanöver - und warum ist es in erster Linie in der Speicherdump?

+0

Ich nehme an, es ist nicht unmöglich. Es umschließt eine AggregateException mit einer ReadOnlyCollection von Exceptions. Ein Jigabyte-Wert von Ausnahmen ist, na ja, etwas, das debuggbar sein sollte. –

+0

@HansPassant ja [1.21 _jigabytes_] (https://tenor.com/view/1point21gigawatts-back-to-the-future-doc-gif-4770027) sollte sicherlich debuggbar sein :) – JSteward

Antwort

1

Es stellt sich heraus, dass dies Teil der Service Fabric-Infrastruktur ist. Stateless-Service-Replikat hooks an Task.UnobservedTaskException für einige interne Überwachung. Es würde sich auch anmutig abmelden. Der zugewiesene Speicher ist aufgrund der dem Replikat zugeordneten Zustandswörterbücher so groß.

+0

Wir sehen das auch. Hast du am Ende einen Weg gefunden, dies auf etwas Vernünftigeres zu reduzieren? Oder bedeutet Ihre Antwort, dass Sie tatsächlich die Größe Ihres Service erwarten? –

+0

@NickDarvey - meine Antwort bedeutet im Wesentlichen, dass Sie die Task.OnobservedTaskException für Zwecke der Speicherleckanalyse ignorieren können, es hat einen Verweis auf Statefull Replica Wörterbücher und deshalb ist es so groß. Mein wirkliches Problem war mit zuverlässigem Wörterbuch; Sie können es hier überprüfen: https://stackoverflow.com/questions/47776645/removing-items-from-reliable-dictionary-doesnt-actually- entfernen- them-from-memory –