Udostępnij za pośrednictwem

Wysokie użycie procesora CPU lub pamięci i zwiększone pętle oczekiwania spin-wait w programie .NET Framework na maszynach wirtualnych przy użyciu procesorów Intel Skylake

Ten artykuł pomaga rozwiązać problem polegający na tym, że wysokie użycie procesora CPU lub pamięci występuje w aplikacjach programu Microsoft .NET Framework na maszynach wirtualnych platformy Azure, które są sterowane przez procesory Intel Skylake.

Oryginalna wersja produktu: .NET Framework
Oryginalny numer KB: 4527212

Objawy

Występuje wyższe niż oczekiwane użycie procesora CPU lub pamięci na maszynach wirtualnych platformy Azure, które zostały ostatnio wdrożone na komputerach, które są sterowane przez procesory Intel Skylake. Zgodnie z firmą Intel ta zmiana wpływa na wydajność maszyny wirtualnej i ogólne obciążenie lub wykonywanie aplikacji.

Problem jest spowodowany wzrostem opóźnienia instrukcji wstrzymania dla procesorów Intel Skylake. Ten problem można zauważyć szczególnie w aplikacjach .NET Framework. Dzieje się tak, ponieważ zmiana opóźnienia wstrzymania ma wpływ na długie pętle oczekiwania na spin-wait, które są wspólne w programie .NET Framework.

Przyczyna

W najnowszej mikroarchitekturze Skylake intel zwiększyła wartość Opóźnienia wstrzymania do 140 cykli. W przypadku mikroarchitektury starszej generacji wartość Opóźnienie wstrzymania wynosi około 10 cykli. Według firmy Intel ta zmiana została wprowadzona w celu poprawy udostępniania zasobów. Aby uzyskać więcej informacji o zmianie i jej skutkach, zobacz sekcję 2.6.4 (Wstrzymaj opóźnienie w microarchitecture klienta Skylake) następującego dokumentu Intel PDF: Intel 64 i IA-32 Architectures Optimization Reference Manual (Podręcznik optymalizacji architektur i architektur IA-32).

Rezolucja

Ważne

Dokładnie wykonaj kroki opisane w tej sekcji. Poważne problemy mogą wystąpić, jeśli nieprawidłowo zmodyfikujesz rejestr. Przed zmodyfikowaniem rejestru należy utworzyć jego kopię zapasową, aby móc przywrócić rejestr na wypadek problemów.

Rozwiązanie tego problemu

Aby rozwiązać ten problem, zainstaluj pakiet zbiorczy zabezpieczeń i jakości programu .NET Framework z października 2018 r.

Uwaga / Notatka

W programie .NET Framework 4.8 poprawka jest domyślnie włączona. W programach .NET Framework 4.6.x i 4.7.x poprawka jest domyślnie wyłączona i można ją włączyć ręcznie.

Aby włączyć poprawkę opóźnienia wstrzymania procesorów Skylake, uruchom Edytor rejestru i dodaj Thread_NormalizeSpinWait klucz jako wartość DWORD do następującego podklucza:

  • Lokalizacja: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework
  • Nazwa wartości: Thread_NormalizeSpinWait
  • Dane wartości: 1

Uwaga / Notatka

Inne aplikacje klienta mogą również mieć wpływ na konfigurację czasomierza, mimo że to ustawienie nie jest domyślnie włączone w żadnej wersji programu .NET Framework. Jeśli wydajność obciążenia nadal ma wpływ na zmianę wstrzymania opóźnienia, rozważ, czy czasomierze są istotnym źródłem rywalizacji o blokadę. Jeśli ustalisz, że jest to prawda, przejdź do sekcji Poprawka czasomierzy .

Poprawka czasomierzy

Aby ręcznie włączyć poprawkę, dodaj Switch.System.Threading.UseNetCoreTimer klucz jako wartość Ciągu do następującego podklucza:

  • Lokalizacja: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AppContext
  • Nazwa wartości: Switch.System.Threading.UseNetCoreTimer
  • Dane wartości: true

Aby uzyskać więcej informacji na temat czasomierzy, zobacz sekcję AppContext dla odbiorców biblioteki w klasie AppContext.

Najczęściej zadawane pytania

  • Czy ta zmiana powoduje jakiekolwiek szkody w przypadku włączenia funkcji UseNetCoreTimer na wszelkiego rodzaju sprzęcie?

    Poprawka czasomierza nie jest obecnie domyślnie włączona w żadnej wersji programu .NET Framework. Nie zalecamy zmiany ustawienia domyślnego na poziomie lokalnym.

  • Czy istnieją inne znane problemy spowodowane zmianą opóźnienia wstrzymania w programie Skylake?

    Nowy pomiar opóźnienia wstrzymania zużywa również dodatkowy czas procesora CPU podczas uruchamiania. Zazwyczaj wartość wynosi około 10 ms czasu procesora CPU. Zwiększony czas trwania jest uważany za niezbędny do uzyskania bardziej niezawodnych pomiarów i zwiększenia możliwości rozwiązania problemu. Jednak aplikacje .NET Framework mogą być również krótkimi narzędziami. Częste korzystanie z takich narzędzi może spowodować większe użycie procesora CPU niż przed zastosowaniem poprawki. Uznano to za akceptowalny kompromis w celu rozwiązania większego problemu i włączenia poprawki domyślnie w programie .NET Framework 4.8.

  • Czy poprawka opóźnienia wstrzymania usługi Skylake ma gwarancję rozwiązania mojego problemu?

    Nie, poprawka nie jest gwarantowana. Mogą istnieć inne, niepowiązane elementy poza tym problemem, które wpływają na wydajność określonego obciążenia. Skuteczność poprawki jest bramowana w zakresie jakości pomiarów. Istnieją ograniczenia, aby upewnić się, że nie przeskalujemy liczby spinów w programie .NET Framework. Jednak nieprawidłowe pomiary mogą wystąpić, gdy maszyna wirtualna jest mocno załadowana. Może to uniemożliwić skuteczne rozwiązanie. W najgorszym przypadku (z wyłączeniem kompromisu wymienionego w A2) sytuacja ta byłaby podobna do poprawki, która nie jest stosowana.

  • Czy mamy jakiekolwiek wskazówki dla inżynierów pomocy technicznej dotyczące tego, jak możemy wykryć, że jakikolwiek postrzegany problem z wydajnością jest spowodowany tą zmianą?

    Można to określić, profilowania używanej aplikacji. Porównanie profilów, które mają podobne obciążenia między maszyną wirtualną opartą na usłudze Skylake i maszyną wirtualną opartą na programie Skylake, może pokazać znacznie więcej czasu stosunkowo spędzonego na clr!AwareLock::Contention maszynie wirtualnej Skylake. Oznaczałoby to, że poprawka opóźnienia wstrzymania byłaby przydatna, jeśli maszyna wirtualna działa na procesorze Skylake.

W przypadku poprawki czasomierza stos wywołań pokazuje, że clr!AwareLock::Contention jest wywoływany przez mscorlib.ni!System.Threading.TimerQueueTimer.Fire()element . Fire() Jeśli metoda lub inne metody są TimerQueueTimer podstawowym źródłem rywalizacji, oznaczałoby to, że poprawka czasomierza pomoże.

Istnieje również możliwość monitorowania współczynników rywalizacji o blokadę przy użyciu monitor wydajności. Aby uzyskać więcej informacji, zobacz sekcję Współczynnik rywalizacji /s i Total # wpisów Rywalizacja o elementy dla parametrów .NET CLR LocksAndThreads w sekcji Liczniki wydajności blokad i wątków w temacie Liczniki wydajności w programie .NET Framework.

Zastrzeżenie dotyczące informacji pochodzących od stron trzecich

Produkty innych firm omówione w tym artykule są produkowane przez firmy, które są niezależne od firmy Microsoft. Firma Microsoft nie udziela żadnych gwarancji, dorozumianych ani żadnego innego rodzaju, w odniesieniu do wydajności lub niezawodności tych produktów.