Wenn unsere ASP.NET-Website stark ausgelastet ist, wird einer der Server hin und wieder einfach verrückt und verwendet 100% CPU, ohne überhaupt zu antworten. Wenn ich stackdump.exe auf den laufenden Prozess laufe, sehe ich, dass praktisch alle Threads in der Methode% co_de enden %. Einige Stacks sehen so aus, als ob unser eigener Code in LocalDataStoreMgr.GetNamedDataSlot , andere GetNamedDataSlot oder HttpApplication.ExecuteStep aufrufen würden. Hier ist ein Ausschnitt aus dem Stack-Dump:
Ich glaube, ich verstehe, was Thread Local Storage ist, aber ich verstehe nicht, warum dieser Anruf anscheinend von diesen Orten aus erfolgt. Wir nennen HttpWriter.Write nicht explizit irgendwo. Weder der BCL-Code in den Methoden, die durch diese Protokolle angezeigt werden (wenn ich ILSpy vertrauen kann).
Warum wird diese Methode so oft aufgerufen? Was soll ich tun, um diese Situation zu verhindern (sieht für mich wie ein Hotspot aus)?
Die GetFromCache-Methode (n) ist unten zu sehen. Das Thread.GetNamedDataSlot -Feld ist statisch. Die Implementierung dieser Klasse, die threadfähigen Code enthält, ist ebenfalls enthalten.
Mehr umfangreiches Code-Snippet hier .
Es stellte sich heraus, dass der seltsame Anruf tatsächlich vom New Relic Agent verursacht wurde. Die Methoden im Fall sind alle instrumentierte Methoden. Mit der Deaktivierung von New Relic ist das Leistungsproblem jedoch nicht verschwunden. Die Stapel waren jedoch informativer. Also Frage beantwortet. @jessehouwing, wenn Sie Ihre Bemerkung als Antwort neu formulieren, würde ich gerne akzeptieren.
Ich habe diese Erklärung gefunden
"Threads verwenden einen lokalen Speichermechanismus, um Thread-spezifische Daten zu speichern. Die Common Language Runtime weist jedem Prozess bei der Erstellung ein Multi-Slot-Datenspeicherarray zu. Der Thread kann im Datenspeicher einen Datenslot zuweisen. Speichern und Abrufen eines Datenwerts im Steckplatz und Freigeben des Steckplatzes zur Wiederverwendung nach Ablauf des Threads Datenschlitze sind pro Thread eindeutig Kein anderer Thread (nicht einmal ein untergeordneter Thread) kann diese Daten abrufen.
Wenn der benannte Steckplatz nicht existiert, wird ein neuer Steckplatz zugewiesen. Benannte Datenslots sind öffentlich und können von jedermann manipuliert werden. "
Die Quelle ist: Ссылка
in diesem Artikel erklären, dass es möglich ist, dieses Verhalten neu zu schreiben
Das Problem, das ich denke, ist, dass .net den gleichen Namen zum Speichern des Steckplatzes wiederverwenden und dies die schlechte Leistung verursachen.
ist möglich als eine Lösung, um die runtime callable wrappers zu bereinigen.
Ich habe das gefunden:
Tags und Links c# multithreading profiling asp.net newrelic