.NetMemory Profiler auf Konsole?

[TomasH]

Hi,

ich suche nach einer Möglichkeit ein Laufendes (.Net) Programm automatisch,
auf Memoryleaks mit einem Profiler zu überprüfen.
Gibt ja ein paar Graphische.

Kennt jemand von euch einen solchen, den man auch per Kommandozeile dazu einfach verwenden kann,
um eine gutes "Ampel"-Ergebnis zu erhalten und auf die Eigenen Namespaces beschränken kann?

Macht vl jemand selbst etwas ähnliches?

[Ralf Jansen]

Möglich. Wenn würde ich dem Ergebnis(wenn du an eine Ampelaussage denkst) aber nicht trauen. In DotNet gibt es bei MemoryLeaks kein Schwarz-Weiss (bzw. Rot-Grün). Das was du in den Tools zu sehen bekommst ist üblicherweise nur der verbrauchte Speicher und vermutete Probleme. Ob ein Speicherbereich zurecht noch referenziert ist oder nicht kann ein Tool eigentlich nicht beurteilen sondern nur schätzen das lange referenzierter (damit nicht freigegebener) Speicher ein Memory Leak darstellt. Könnte aber auch nur ein Singleton sein der über die gesamte Programmlaufzeit existiert.

[gfoidl]

Hallo,

der Visual Studio Profiler und der CLR Profiler (auch von MS, kostenlos) gehen per Befehlszeile und können an laufende Programme angehängt werden.

mfG Gü

[TomasH]

Also mit Ampel ... muss ich vl erklären.
Ich hatte mal in einem Praktikum (lang lang ists her) ... man konnte einfach zwei snapshots machen und die wurden sofort vergglichen.
Bei jedem Issue wurde dann mit Farbpunkt angezeigt wie scher der fehler ist.

Dachte eben auch daran, dass ich das dann so autoatisch machen kann:
Profiler an Prozess attatchen.
Shapshot - paar sachen machen (möglichst automatisiert) - snapshot --> analyse
Das Ergebniss sollte dann ein Report sein (HTML wäre nett) und vl ein "gewichtiger Ergebniswert" der hald aussagt Critical error (memLeak) bis hin da kann kein Fehler sein.

Wollt daher auch mal fragen ob eben wer von euch schon mal per Kommandozeile sowas gemacht hat.

[Ralf Jansen]

Attachen, Snapshot machen etc. solltest du mit dem genannten Clr Profiler hinbekommen einfach mal die Doku lesen. Das mit dem Issue erkennen und gewichten ist ein Problem. Wenn du ausschließlichen Net Code hast gibt es keine Memory Leaks im klassischen Sinn (Bugs im Garbage Collector des Frameworks mal ausgeschlossen) und damit nicht einfach die Aussage 'oh ich habe nicht mehr referenzierten Speicher das muss ein Speicherleck sein'. Es gibt nur unnötig weiterhin referenzierten Speicher. Das kann aber nur ein intelligenter Beobachter feststellen ob das Objekt noch gebraucht wird oder nicht. Das kann nicht durch einen Automatismus ersetzt werden.

Was du machen könntest wäre also 2 Snapshot daraus 2 Berichte generieren (Aufbereiten das die vergleichbar werden, vielleicht bekommt man dann noch automatisch ein Diff aus den beiden hin) und dann manuell (durch jemanden mit konkretem Wissen über die überprüfte Anwendung) überprüfen lassen ob da was faul ist. Diese Person ist aber nicht durch einen Algorithmus ersetzbar(außer einen der für eine konkrete Anwendung geschrieben wird und dann vermutlich die gleiche Komplexität hat wie die Anwendung).

[TomasH]

Attachen, Snapshot machen etc. solltest du mit dem genannten Clr Profiler hinbekommen einfach mal die Doku lesen. Das mit dem Issue erkennen und gewichten ist ein Problem. Wenn du ausschließlichen Net Code hast gibt es keine Memory Leaks im klassischen Sinn (Bugs im Garbage Collector des Frameworks mal ausgeschlossen) und damit nicht einfach die Aussage 'oh ich habe nicht mehr referenzierten Speicher das muss ein Speicherleck sein'. Es gibt nur unnötig weiterhin referenzierten Speicher. Das kann aber nur ein intelligenter Beobachter feststellen ob das Objekt noch gebraucht wird oder nicht. Das kann nicht durch einen Automatismus ersetzt werden.

Was du machen könntest wäre also 2 Snapshot daraus 2 Berichte generieren (Aufbereiten das die vergleichbar werden, vielleicht bekommt man dann noch automatisch ein Diff aus den beiden hin) und dann manuell (durch jemanden mit konkretem Wissen über die überprüfte Anwendung) überprüfen lassen ob da was faul ist. Diese Person ist aber nicht durch einen Algorithmus ersetzbar(außer einen der für eine konkrete Anwendung geschrieben wird und dann vermutlich die gleiche Komplexität hat wie die Anwendung).

Hi,
Also der Profiler den wir damals hatten erzeugte einen Bericht aus den zwei Snapshots.
Wie das mit der Gewichtung lief, weiß ich natürlich nicht, aber vl waren da "Erfahrungsreferenzen" hinterlegt.
Sprich
-> Könnte nach einem Fehler aussehen?
--> Ist (statistisch) auch selten/manchmal/oft ein Fehler
----> Wenn ein Fehler wie schwer (wie oft aufgerufen,...)
An Hand dieser Isue Meldungen hat sich der Entwickler alles (priorisiert) der reihe nach angeschaut,
je nach dem wieviel Zeit er hatte .... von Oben nach unten.

Wichtig ist ja bei dem Automatischen ausführen nicht genau einen track down zu den Fehlern zu haben,
sondern zu wissen, Sieht eigentlich "OK" aus, "Da gibts paar sachen zum anschauen/ ich habe keine Ahnung", "Kritischer Fehler".
Damit der Entwickler sieht wie sehr der Hut brennt. Je nach dem an wie vielen ecken es sonst noch brennt macht er sich dann ran.

Werde mir aber mal den CLR einfach am WE ansehen.