Hohe CPU- oder Arbeitsspeicherauslastung und erhöhte Drehwarteschleifen in .NET Framework auf VMs mit Intel Skylake-Prozessoren

  • Artikel
  • 4 Minuten Lesedauer

Dieser Artikel hilft Ihnen, das Problem zu beheben, bei dem eine hohe CPU- oder Speicherauslastung in Microsoft .NET Framework-Anwendungen auf virtuellen Azure-Computern (VMs) auftritt, die von Intel Skylake-Prozessoren gesteuert werden.

Ursprüngliche Produktversion:   .NET Framework
Ursprüngliche KB-Nummer:   4527212

Problembeschreibung

Die CPU- oder Speicherauslastung ist auf Azure-VMs höher als erwartet, die kürzlich auf Computern bereitgestellt wurden, die von Intel Skylake-Prozessoren gesteuert werden. Laut Intel wirkt sich diese Änderung auf die VM-Leistung und die gesamte Workload oder Anwendungsausführung aus.

Das Problem wird durch eine Erhöhung der Pausenanweisungsverzögerung für Intel Skylake-Prozessoren verursacht. Dieses Problem kann insbesondere in .NET Framework Anwendungen auftreten. Dies liegt daran, dass sich die Änderung der Pause Latency auf lange Drehwarteschleifen auswirkt, die in .NET Framework häufig vorkommen.

Ursache

In der neuesten Skylake-Mikroarchitektur hat Intel den Pause Latency-Wert auf bis zu 140 Zyklen erhöht. In früheren Mikroarchitekturen der älteren Generation beträgt der Pause Latency-Wert etwa 10 Zyklen. Laut Intel wurde diese Änderung vorgenommen, um die Ressourcenfreigabe zu verbessern. Weitere Informationen zu der Änderung und ihren Auswirkungen finden Sie in Abschnitt 8.4.7 des folgenden Intel PDF-Dokuments: Intel 64 und IA-32 Architectures Optimization Reference Manual.

Lösung

Wichtig

Führen Sie die in diesem Abschnitt beschriebenen Schritte sorgfältig aus. Durch eine fehlerhafte Bearbeitung der Registrierung können schwerwiegende Probleme verursacht werden. Sichern Sie die Registrierung, bevor Sie sie ändern, damit Sie sie bei Bedarf wiederherstellen können.

Behebung dieses Problems

Um dieses Problem zu beheben, installieren Sie .NET Framework October 2018 Security and Quality RollUp.

Hinweis

In .NET Framework 4.8 ist der Fix standardmäßig aktiviert. In .NET Framework 4.6.x und 4.7.x ist der Fix standardmäßig deaktiviert und kann manuell aktiviert werden.

Um die Korrektur für die Pausenverzögerung auf Skylake-Prozessoren zu aktivieren, starten Sie den Registrierungs-Editor, und fügen Sie den Thread_NormalizeSpinWait Schlüssel als DWORD-Wert zum folgenden Unterschlüssel hinzu:

  • Lage: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework
  • Wertname: Thread_NormalizeSpinWait
  • Wertdaten: 1

Hinweis

Andere Kundenanwendungen sind möglicherweise auch von der Timerkonfiguration betroffen, obwohl diese Einstellung in keiner Version von .NET Framework standardmäßig aktiviert ist. Wenn die Arbeitsauslastungsleistung nach der Änderung der Pausenlatenz weiterhin beeinträchtigt wird, sollten Sie überlegen, ob Timer eine erhebliche Quelle von Sperrkonflikten sind. Wenn Sie feststellen, dass dies der Fall ist, wechseln Sie zum Abschnitt "Fix" für den Timerabschnitt.

Fix für die Timer

Um die Korrektur manuell zu aktivieren, fügen Sie den Switch.System.Threading.UseNetCoreTimer Schlüssel dem folgenden Unterschlüssel als Zeichenfolgenwert hinzu:

  • Lage: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AppContext
  • Wertname: Switch.System.Threading.UseNetCoreTimer
  • Wertdaten: true

Weitere Informationen zu Timern finden Sie im Abschnitt "AppContext für Bibliothekskunden" in der AppContext-Klasse.

Häufig gestellte Fragen

  • Verursacht diese Änderung einen Schaden, wenn auch UseNetCoreTimer auf allen Arten von Hardware aktiviert ist?

    Die Zeitgeberkorrektur ist derzeit in keiner Version von .NET Framework standardmäßig aktiviert. Es wird nicht empfohlen, die Standardeinstellung auf lokaler Ebene zu ändern.

  • Gibt es weitere bekannte Probleme, die durch die Pause Latency-Änderung in Skylake verursacht werden?

    Die neue Pause Latency-Messung verbraucht auch zusätzliche CPU-Zeit während des Starts. In der Regel beträgt der Wert ca. 10 ms CPU-Zeit. Die erhöhte Dauer wird als notwendig betrachtet, um zuverlässigere Messungen zu erhalten und die Fähigkeit zur Behebung des Problems zu verbessern. .NET Framework Anwendungen können jedoch auch kurz ausgeführte Tools sein. Die häufige Verwendung solcher Tools kann zu einer höheren CPU-Auslastung führen als vor der Anwendung des Fixs. Dies wurde als akzeptabler Kompromiss betrachtet, um ein größeres Problem zu beheben und die Korrektur standardmäßig in .NET Framework 4.8 zu aktivieren.

  • Ist die Lösung meines Problems durch den Skylake Pause Latency-Fix garantiert?

    Nein, die Korrektur ist nicht garantiert. Es kann andere, nicht verbundene Elemente außerhalb dieses Problems geben, die sich auf die spezifische Arbeitsauslastungsleistung auswirken. Die Effektivität des Fixs hängt von der Messqualität ab. Es werden Grenzen verwendet, um sicherzustellen, dass wir die Anzahl der Drehungen in .NET Framework nicht überstufen. Allerdings können schlechte Messungen auftreten, wenn der virtuelle Computer stark geladen ist. Dadurch kann verhindert werden, dass der Fix wirksam wird. Im schlechtesten Fall (ohne den in A2 erwähnten Kompromiss) wäre diese Situation ähnlich wie der Fix, der nicht angewendet wird.

  • Haben wir Unterstützung für Supporttechniker, wie wir erkennen können, dass ein wahrgenommenes Leistungsproblem durch diese Änderung verursacht wird?

    Sie können dies ermitteln, indem Sie die verwendete Anwendung profilieren. Der Vergleich von Profilen, die ähnliche Lasten zwischen einer vor Skylake-basierten VM und einem Skylake-basierten virtuellen Computer haben, zeigt möglicherweise viel mehr Zeit, die relativ clr!AwareLock::Contention auf dem virtuellen Skylake-Computer aufgewendet wurde. Dies würde darauf hinweisen, dass die Unterbrechungsverzögerungskorrektur nützlich wäre, wenn der virtuelle Computer auf einem Skylake-Prozessor ausgeführt wird.

Für die Zeitgeberkorrektur zeigt die Aufrufliste an, dass clr!AwareLock::Contention sie von aufgerufen mscorlib.ni!System.Threading.TimerQueueTimer.Fire() wird. Wenn die Fire() Methode oder andere Methoden die primäre Quelle des Inhalts TimerQueueTimer sind, würde dies darauf hinweisen, dass die Zeitgeberkorrektur hilfreich wäre.

Es ist auch möglich, die Sperrkonfliktraten mithilfe des Leistungsmonitors zu überwachen. Weitere Informationen finden Sie im Abschnitt "Contention Rate/Sec" und "Total # of Contentions entries for .NET CLR LocksAndThreads" im Abschnitt "Lock and thread performance counters" in Performance Counters in the .NET Framework.

Informationen zum Haftungsausschluss von Drittanbietern

Die in diesem Artikel genannten Drittanbieterprodukte stammen von Herstellern, die von Microsoft unabhängig sind. Microsoft gewährt keine implizite oder sonstige Garantie in Bezug auf die Leistung oder Zuverlässigkeit dieser Produkte.