Poważne problemy z wydajnością naszego produkcyjnego programu SQL Server. Jak mam to rozwiązać?

To pytanie jest w zasadzie pytaniem uzupełniającym do tego pytania:
Dziwny problem z wydajnością w SQL Server 2016

Teraz osiągnęliśmy produktywność dzięki temu systemowi. Chociaż do mojego programu SQL Server dodano kolejną bazę danych aplikacji od mojego ostatniego postu.

są to statystyki systemowe:

• 128 GB pamięci RAM (maks. 110 GB pamięci dla programu SQL Server)
• 4 rdzenie przy 2,6 GHz
• Połączenie sieciowe 10 GBit
• Cała pamięć jest oparta na dyskach SSD
• Pliki programów, pliki dziennika, pliki bazy danych i tempdb znajdują się na osobnych partycjach serwera
• Windows Server 2012 R2
• Wersja VMware HPE-ESXi-6.0.0-Update3-iso-600.9.7.0.17
• VMware Tools w wersji 10.0.9, kompilacja 3917699
• Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64) 28 października 2016 18:17:30 Prawa autorskie (c) Microsoft Corporation Standard Edition (64-bit) na Windows Server 2012 R2 Standard 6.3 (kompilacja 9600:) (Hypervisor)

Nasz system ma teraz poważne problemy z wydajnością. Bardzo wysokie użycie procesora i liczba wątków:

Czekaj statystyki monitora aktywności (wiem, że nie jest to bardzo wiarygodne)

Wyniki sp_blitzfirst:

Wyniki sp_configure:

Zaawansowane ustawienia serwera (niestety tylko w języku niemieckim)

Ustawienie MAXDOP zostało zmienione przeze mnie.

Wiem, że prawdopodobnie nie jest to problem z samym SQL Server . Prawdopodobnie jest to problem z wirtualizacją (vmware), związany z siecią (już to przetestowałem) lub samą aplikacją. Chcę to jeszcze bardziej ulepszyć.

Czy wysoki ASYNC_NETWORK_IO spowodowałby wysoką liczbę wątków dla procesu serwera sqlserver? Wyobrażam sobie, że to dotyczy wielu pracowników, ponieważ wątków nie można zamknąć. Czy to prawda?

Podam wszelkie dodatkowe informacje, których potrzebujesz. Z góry dziękuję za pomoc!

EDYTOWAĆ:

Wynik sp_Blitz @OutputType = ‘markdown’, @CheckServerInfo = 1

Priorytet 1: Kopia zapasowa :

• Tworzenie kopii zapasowej na tym samym dysku, na którym znajdują się bazy danych - 5 kopii zapasowych wykonanych na dysku E: \ w ciągu ostatnich dwóch tygodni, w których również znajdują się pliki bazy danych. Stanowi to poważne ryzyko, jeśli tablica ulegnie awarii.

Priorytet 1: Niezawodność :

• Ostatni dobry DBCC CHECKDB w wieku powyżej 2 tygodni

  • babtec_prod - Ostatni udany CHECKDB: 2017-08-20 00: 01: 01.513

  • D3PR - Ostatni udany CHECKDB: nigdy.

  • DEMO77 - Ostatni udany CHECKDB: 23.02.2016 20: 31: 38.590

  • FINP - Ostatni udany CHECKDB: 23.04.2017 22: 01: 19.133

  • GridVis_EnMs - Ostatni udany CHECKDB: 2017-05-18 22: 10: 48.120

  • master - Ostatni udany CHECKDB: nigdy.

  • Model

  • msdb

  • PROD77 - Ostatni udany CHECKDB: 23.02.2016 21: 33: 24.343

Priorytet 10: Wydajność :

• Magazyn zapytań wyłączony - Nowa funkcja magazynu zapytań programu SQL Server 2016 nie została włączona w tej bazie danych.

  • babtec_prod

  • D3PR

  • DEMO77

  • FINP

  • GridVis_EnMs

Priorytet 50: Zdarzenia DBCC :

• DBCC DROPCLEANBUFFERS - Schorsch użytkownika uruchomił DBCC DROPCLEANBUFFERS 1 razy między 21 września 2017 11:57 a 21 września 2017 11:57. Jeśli jest to skrzynka produkcyjna, wiedz, że kiedy to się dzieje, usuwasz wszystkie dane z pamięci. Jaki potwór by to zrobił?

• DBCC SHRINK% - Schorsch użytkownika uruchomił skurczenie pliku 6 razy między 21 września 2017 23:51 a Okt 4 2017 09:02. Więc, oni próbują naprawić korupcję, czy spowodować korupcję?

• Wydarzenia ogólne - 287 wydarzeń DBCC odbyło się między 19 września 2017 13:40 a Okt 4 2017 15:20. Nie obejmuje to CHECKDB i innych zwykle łagodnych zdarzeń DBCC.

Priorytet 50: Wydajność :

• Powolne wzrosty plików PROD77 - każdy z 2 wzrostów zajął ponad 15 sekund. Rozważ ustawienie autogrowth pliku na mniejszą wartość.

Priorytet 50: Niezawodność :

• Weryfikacja strony nie jest optymalna babtec_prod - Baza danych [babtec_prod] ma TORN_PAGE_DETECTION do weryfikacji strony. SQL Server może mieć trudniejsze rozpoznanie i odzyskanie po uszkodzeniu pamięci. Zamiast tego rozważ użycie CHECKSUM.

Priorytet 100: Wydajność :

• Wiele planów dla jednego zapytania - 3576 planów jest dostępnych dla pojedynczego zapytania w pamięci podręcznej planu - co oznacza, że ​​prawdopodobnie mamy problemy z parametryzacją.

Priorytet 110: Wydajność :

• Aktywne tabele bez indeksów klastrowych

  • babtec_prod - baza danych [babtec_prod] zawiera sterty - tabele bez indeksu klastrowego - które są aktywnie wyszukiwane.

  • D3PR - baza danych [D3PR] zawiera sterty - tabele bez indeksu klastrowego - które są aktywnie przeszukiwane.

  • DEMO77 - baza danych [DEMO77] zawiera sterty - tabele bez indeksu klastrowego - które są aktywnie przeszukiwane.

  • FINP - baza danych [FINP] zawiera sterty - tabele bez indeksu klastrowego - które są aktywnie przeszukiwane.

  • GridVis_EnMs - baza danych [GridVis_EnMs] zawiera sterty - tabele bez indeksu klastrowego - które są aktywnie wyszukiwane.

  • PROD77 - baza danych [PROD77] zawiera sterty - tabele bez indeksu klastrowego - które są aktywnie przeszukiwane.

Priorytet 150: Wydajność :

• Klucze zagraniczne nie są zaufane

  • babtec_prod - baza danych [babtec_prod] zawiera klucze obce, które prawdopodobnie zostały wyłączone, dane zostały zmienione, a następnie klucz został ponownie włączony. Samo włączenie klucza nie wystarczy, aby optymalizator mógł użyć tego klucza - musimy zmienić tabelę za pomocą parametru Z KONTRAKTEM KONTROLNYM SPRAWDŹ KONTROLĘ.

  • D3PR - baza danych [D3PR] zawiera klucze obce, które prawdopodobnie zostały wyłączone, dane zostały zmienione, a następnie klucz został ponownie włączony. Samo włączenie klucza nie wystarczy, aby optymalizator mógł użyć tego klucza - musimy zmienić tabelę za pomocą parametru Z KONTRAKTEM KONTROLNYM SPRAWDŹ KONTROLĘ.

• Nieaktywne tabele bez indeksów klastrowych

  • D3PR - baza danych [D3PR] zawiera sterty - tabele bez indeksu klastrowego - które nie były sprawdzane od ostatniego restartu. Mogą to być niedbale pozostawione tabele zapasowe.

  • GridVis_EnMs - baza danych [GridVis_EnMs] zawiera sterty - tabele bez indeksu klastrowanego - które nie były odpytywane od ostatniego restartu. Mogą to być niedbale pozostawione tabele zapasowe.

• Wyzwalacze w tabelach babtec_prod - Baza danych [babtec_prod] ma 26 wyzwalaczy.

Priorytet 170: Konfiguracja pliku :

• Systemowa baza danych na dysku C.

  • master - główna baza danych ma plik na dysku C. Umieszczenie systemowych baz danych na dysku C grozi awarią serwera, gdy zabraknie miejsca.

  • model - baza danych modelu ma plik na dysku C. Umieszczenie systemowych baz danych na dysku C grozi awarią serwera, gdy zabraknie miejsca.

  • msdb - baza danych msdb ma plik na dysku C. Umieszczenie systemowych baz danych na dysku C grozi awarią serwera, gdy zabraknie miejsca.

Priorytet 170: Niezawodność :

• Ustaw maksymalny rozmiar pliku

  • D3PR - maksymalny rozmiar pliku bazy danych [D3PR] d3_data_01 wynosi 61440 MB. Jeśli zabraknie miejsca, baza danych przestanie działać, nawet jeśli może być dostępne miejsce na dysku.

  • D3PR - maksymalny rozmiar pliku bazy danych [D3PR] d3_data_idx_01 wynosi 61440 MB. Jeśli zabraknie miejsca, baza danych przestanie działać, nawet jeśli może być dostępne miejsce na dysku.

  • D3PR - maksymalny rozmiar pliku bazy danych [D3PR] d3_firm_01 wynosi 61440 MB. Jeśli zabraknie miejsca, baza danych przestanie działać, nawet jeśli może być dostępne miejsce na dysku.

  • D3PR - maksymalny rozmiar pliku bazy danych [D3PR] d3_firm_idx_01 wynosi 61440 MB. Jeśli zabraknie miejsca, baza danych przestanie działać, nawet jeśli może być dostępne miejsce na dysku.

  • D3PR - plik bazy danych [D3PR] d3_log_01 ma maksymalny rozmiar pliku ustawiony na 61440 MB. Jeśli zabraknie miejsca, baza danych przestanie działać, nawet jeśli może być dostępne miejsce na dysku.

  • D3PR - maksymalny rozmiar pliku bazy danych [D3PR] d3_phys_01 wynosi 61440 MB. Jeśli zabraknie miejsca, baza danych przestanie działać, nawet jeśli może być dostępne miejsce na dysku.

  • D3PR - maksymalny rozmiar pliku bazy danych [D3PR] d3_phys_idx_01 wynosi 61440 MB. Jeśli zabraknie miejsca, baza danych przestanie działać, nawet jeśli może być dostępne miejsce na dysku.

  • D3PR - plik bazy danych [D3PR] d3_sys_01 ma maksymalny rozmiar pliku ustawiony na 20480 MB. Jeśli zabraknie miejsca, baza danych przestanie działać, nawet jeśli może być dostępne miejsce na dysku.

  • D3PR - maksymalny rozmiar pliku bazy danych [D3PR] d3_usr_01 wynosi 20480 MB. Jeśli zabraknie miejsca, baza danych przestanie działać, nawet jeśli może być dostępne miejsce na dysku.

  • D3PR - plik bazy danych [D3PR] d3_wort_01 ma maksymalny rozmiar pliku ustawiony na 20480 MB. Jeśli zabraknie miejsca, baza danych przestanie działać, nawet jeśli może być dostępne miejsce na dysku.

  • D3PR - plik bazy danych [D3PR] d3_wort_idx_01 ma maksymalny rozmiar pliku ustawiony na 20480 MB. Jeśli zabraknie miejsca, baza danych przestanie działać, nawet jeśli może być dostępne miejsce na dysku.

Priorytet 200: Informacyjny :

• Kompresja kopii zapasowej Domyślnie wyłączona - Niedawno pojawiły się nieskompresowane pełne kopie zapasowe, a kompresja kopii zapasowej nie jest włączona na poziomie serwera. Kompresja kopii zapasowych jest zawarta w SQL Server 2008R2 i nowszych, nawet w wersji Standard. Zalecamy domyślnie włączyć kompresję kopii zapasowych, aby kopie zapasowe ad hoc uległy kompresji.

• Sortowanie jest Latin1_General_CS_AS FINP - Różnice w sortowaniu między bazami danych użytkowników a tempdb mogą powodować konflikty, szczególnie przy porównywaniu wartości ciągów

• Sortowanie to SQL_Latin1_General_CP1_CI_AS - Różnice w sortowaniu między bazami danych użytkowników a tempdb mogą powodować konflikty, szczególnie przy porównywaniu wartości ciągów

  • DEMO77

  • PROD77

• Skonfigurowany serwer połączony - BWIN2 \ INFOR jest skonfigurowany jako serwer połączony. Sprawdź konfigurację zabezpieczeń podczas łączenia się z sa, ponieważ każdy użytkownik, który go zapyta, uzyska uprawnienia na poziomie administratora.

Priorytet 200: Monitorowanie :

• E-maile o zadaniach agenta bez awarii

  • Zadanie syspolicy_purge_history nie zostało skonfigurowane do powiadamiania operatora, jeśli się nie powiedzie.

  • Zadanie upd_durchpreis_monatl nie zostało skonfigurowane do powiadamiania operatora, jeśli się nie powiedzie.

  • Zadanie upd_fertmengen_woche nie zostało skonfigurowane do powiadamiania operatora, jeśli się nie powiedzie.

  • Zadanie upd_liegezeit_monatl nie zostało skonfigurowane do powiadamiania operatora, jeśli się nie powiedzie.

  • Zadanie upd_vertreter_diff nie zostało skonfigurowane do powiadamiania operatora, jeśli się nie powiedzie.

  • Zadanie UPDATE_CONNECT_IK nie zostało skonfigurowane do powiadamiania operatora, jeśli się nie powiedzie.

  • Zadanie Wartung.Cleanup nie zostało skonfigurowane do powiadamiania operatora, jeśli się nie powiedzie.

  • Zadanie Wartung.DBCC Check DB nie zostało skonfigurowane do powiadamiania operatora, jeśli się nie powiedzie.

  • Zadanie Wartung.Index neu erstellen nie zostało skonfigurowane w celu powiadamiania operatora o awarii.

  • Zadanie Wartung.Statistiken aktualisieren nie zostało skonfigurowane w celu powiadamiania operatora o awarii.

  • Zadanie Wartung.Transactionlog Backup nie zostało skonfigurowane do powiadamiania operatora w przypadku niepowodzenia.

  • Zadanie Wartung.Vollbackup SystemDB nie zostało skonfigurowane w celu powiadamiania operatora o awarii.

  • Zadanie Wartung.Vollbackup UserDB nie zostało skonfigurowane do powiadamiania operatora, jeśli się nie powiedzie.

• Brak alertów o uszkodzenie - Alerty agenta SQL Server nie istnieją dla błędów 823, 824 i 825. Te trzy błędy mogą dać ci powiadomienie o wczesnej awarii sprzętu. Włączenie ich może zapobiec wielu złamaniom serca.

• Brak alertów dla Sev 19-25 - Alarmy agenta SQL Server nie istnieją dla poziomów ważności od 19 do 25. Są to bardzo poważne błędy SQL Server. Świadomość, że tak się dzieje, może pomóc w szybszym odzyskaniu błędów.

• Nie wszystkie alerty skonfigurowane - nie wszystkie alerty agenta SQL Server zostały skonfigurowane. Jest to darmowy, łatwy sposób powiadamiania o korupcji, awariach pracy lub poważnych awariach nawet przed wykryciem systemów monitorowania.

Priorytet 200: Domyślna konfiguracja serwera :

• Agent XPs - Ta opcja sp_configure została zmieniona. Jego domyślna wartość to 0 i została ustawiona na 1.

• Bazy danych poczty XP - Ta opcja sp_configure została zmieniona. Jego domyślna wartość to 0 i została ustawiona na 1.

• domyślny język pełnotekstowy - Ta opcja sp_configure została zmieniona. Jego domyślna wartość to 1033 i została ustawiona na 1031.

• język domyślny - Ta opcja sp_configure została zmieniona. Jego domyślna wartość to 0 i została ustawiona na 1.

• poziom dostępu do strumienia plików - ta opcja sp_configure została zmieniona. Jego domyślna wartość to 0 i została ustawiona na 1.

• maksymalny stopień równoległości - Ta opcja sp_configure została zmieniona. Jego domyślna wartość to 0 i została ustawiona na 4.

• maksymalna pamięć serwera (MB) - Ta opcja sp_configure została zmieniona. Jego domyślna wartość to 2147483647 i została ustawiona na 115000.

• min pamięć serwera (MB) - Ta opcja sp_configure została zmieniona. Jego domyślna wartość to 0 i została ustawiona na 10000.

• połączenia z administratorem zdalnym - Ta opcja sp_configure została zmieniona. Jego domyślna wartość to 0 i została ustawiona na 1.

Priorytet 200: Wydajność :

• próg kosztu dla równoległości - Ustawiony na 5, jego wartość domyślna. Zmiana tego ustawienia sp_configure może zmniejszyć oczekiwania CXPACKET.

• Wystąpiły kopie zapasowe migawek - w ciągu ostatnich dwóch tygodni wystąpiło 9 kopii zapasowych wyglądających na migawki, co wskazuje, że IO może się zawiesić.

Priorytet 210: Domyślna konfiguracja bazy danych :

• Czytaj zatwierdzone izolowanie migawek włączone - To ustawienie bazy danych nie jest domyślne.

  • D3PR

  • FINP

• Włączone wyzwalacze rekurencyjne - To ustawienie bazy danych nie jest domyślne.

  • DEMO77

  • PROD77

• Snapshot Isolation Enabled FINP - To ustawienie bazy danych nie jest domyślne.

Priorytet 240: Statystyki czekania :

• 1 - ASYNC_NETWORK_IO - 225,9 godziny oczekiwania, średni czas oczekiwania 143,5 minuty na godzinę, oczekiwanie sygnału 0,2%, zadania oczekiwania 2146022, średni czas oczekiwania 378,9 ms.

• 2 - CXPACKET - 43,1 godziny oczekiwania, średni czas oczekiwania 27,4 minuty na godzinę, oczekiwanie na sygnał 1,5%, zadania oczekiwania 32608391, średni czas oczekiwania 4,8 ms.

Priorytet 250: Informacyjny :

• SQL Server działa na koncie usługi NT

  • Pracuję jako NT Service \ MSSQL $ INFOR. Chciałbym mieć zamiast tego konto usługi Active Directory.

  • Pracuję jako NT Service \ SQLAgent $ INFOR. Chciałbym mieć zamiast tego konto usługi Active Directory.

Priorytet 250: Informacje o serwerze :

• Domyślna zawartość śledzenia - Domyślny ślad zawiera 760 godzin danych między 3 września 2017 20:34 a Okt 5 2017 12:50. Domyślne pliki śledzenia znajdują się w: C: \ Program Files \ Microsoft SQL Server \ MSSQL13.INFOR \ MSSQL \ Log

• Dysk C Space - 21308,00 MB za darmo na dysku C.

• Dysk D Space - 280008,00 MB za darmo na dysku D.
• Dysk E Space - 281618.00 MB bezpłatnie na dysku E.

• Dysk F Space - 60193,00 MB za darmo na dysku F.

• Sprzęt - procesory logiczne: 4. Pamięć fizyczna: 128 GB.

• Sprzęt - Konfiguracja NUMA - Węzeł: 0 Stan: ONLINE Planiści online: 4 Planiści offline: 0 Grupa procesorów: 0 Węzeł pamięci: 0 Zarezerwowany VAS pamięci GB: 281

• Ostatnie uruchomienie serwera - 1 października 2017 14:21

• Nazwa serwera - BWINPDB \ INFOR

• Usługi

  • Usługa: SQL Server (INFOR) działa na koncie usługi NT Service \ MSSQL $ INFOR. Czas ostatniego uruchomienia: Okt 1 2017 14:22. Typ uruchomienia: Automatyczny, obecnie uruchomiony.

  • Usługa: SQL Server-Agent (INFOR) działa na koncie usługi NT Service \ SQLAgent $ INFOR. Czas ostatniego uruchomienia: nie pokazano. Typ uruchomienia: Automatyczny, obecnie uruchomiony.

• Ostatnie uruchomienie programu SQL Server - 1 października 2017 14:22

• Usługa SQL Server - wersja: 13.0.4001.0. Poziom łaty: SP1. Edycja: edycja standardowa (64-bitowa). AlwaysOn włączone: 0. AlwaysOn Mgr Status: 2

• Serwer wirtualny - Typ: (HYPERVISOR)

• Wersja systemu Windows - korzystasz z całkiem nowoczesnej wersji systemu Windows: era Server 2012R2, wersja 6.3

Priorytet 254: Podsumowanie :

• Dziennik kapitana: opóźnij coś i coś ...

EDYTOWAĆ:

Już przestudiowałem ten przewodnik najlepszych praktyk dotyczących konfigurowania serwera SQL z vmware i większość z nich ustawiliśmy zgodnie z tym artykułem. Jednak hiperwątkowanie nie jest aktywowane, a NUMA nie jest aktywne na hoście vmware. SQL Server jest ustawiony na NUMA.

EDYTOWAĆ:

Wydałem RECONFIGURE po ustawieniu progu równoległości na 50, również moje ustawienie MAXDOP nie zostało skonfigurowane.

Sprawdziłem również z naszym administratorem vmware, wygląda na to, że zostałem źle poinformowany. Nasze procesory są ustawione na 2,6 GHz, a nie 4,6 GHz. Poprawiłem powyższe informacje.

EDYTOWAĆ:

Próbowaliśmy ustawić niektóre związane z siecią zgodnie z tym vmwarekb i przewodnikiem . Dodaliśmy także 4 kolejne rdzenie do maszyny wirtualnej. Użycie procesora pozostało takie samo.

Jak omówiono podczas ostatniego zadawania tego pytania , najwyższy czas oczekiwania to ASYNC_NETWORK_IO. SQL Server siedzi i czeka, aż komputer na drugim końcu potoku przetworzy następny wiersz wyników zapytania.

Otrzymałem te informacje z wyników statystyk sp_Blitz (dzięki za wklejenie):

1 - ASYNC_NETWORK_IO - 225,9 godziny oczekiwania, średni czas oczekiwania 143,5 minuty na godzinę, oczekiwanie sygnału 0,2%, zadania oczekiwania 2146022, średni czas oczekiwania 378,9 ms.

Nie odchodź od rozwiązywania problemów z wątkami procesora - to nie jest powiązane. Skoncentruj się na głównym typie oczekiwania i rzeczach, które spowodowałyby ten typ oczekiwania.

Aby rozwiązać ten problem dalej, uruchom sp_WhoIsActive lub sp_BlitzFirst (zastrzeżenie: jestem jednym z autorów tego) - oba z nich wyświetlą aktualnie uruchomione zapytania. Spójrz na kolumnę informacji o czekaniu, znajdź zapytania oczekujące na ASYNC_NETWORK_IO i spójrz na aplikacje i serwery, z których działają.

Stamtąd możesz spróbować:

• Sprawdzanie, czy te serwery aplikacji są słabo zasilane (np. Czy są one maksymalnie obciążone na procesorze lub stronicowanie na dysk) i dostroić je
• Współpracując z twórcami aplikacji, aby sprawdzić, czy przetwarzają wyniki wiersz po rzędzie (tak jak w przypadku każdego wiersza, który wraca z SQL Server, aplikacja wyłącza się i wykonuje pewne przetwarzanie przed zapytaniem o kolejny wiersz wyników)
• Praca z twórcami aplikacji w celu wybrania mniejszej liczby danych (np. Mniej wierszy lub mniej kolumn, jeśli nie potrzebują wszystkich danych - czasami pojawia się to, gdy ludzie przypadkowo robią WYBIERZ * i przynoszą więcej danych, niż potrzebują, lub proszą o wszystkie wiersze, gdy naprawdę potrzebują tylko pierwszej 1000)

Zaktualizuj za pomocą sp_WhoIsActive - na opublikowanym zrzucie ekranu sp_WhoIsActive masz kilka zapytań, które czekają na ASYNC_NETWORK_IO. W tym celu zapoznaj się z powyższymi instrukcjami.

W pozostałej części zapytań spójrz na kolumnę „status” sp_WhoIsActive - większość z nich „śpi”. Oznacza to, że w ogóle nie działają - czekają, aż aplikacje na drugim końcu potoku wyślą swoje następne polecenie. Mają otwarte transakcje (patrz kolumna „open_tran_count”), ale SQL Server nie może nic zrobić, aby przyspieszyć uśpioną transakcję. Te zapytania były otwarte od ponad czterdziestu minut (pierwsza kolumna w sp_WhoIsActive. Po prostu już nic nie robią. Musisz skłonić tych ludzi do zatwierdzania transakcji i zamykania połączeń. To nie jest problem z dostrajaniem wydajności.

Wszystko, co tutaj widzimy, wskazuje na scenariusz, w którym czekamy na aplikację.

Aby odpowiedzieć na własne pytanie. ASYNC_NETWORK_IO faktycznie nie był prawdziwym problemem. Rozwiązaliśmy problem z wydajnością, postępując zgodnie z tym przewodnikiem dla obciążeń wrażliwych na opóźnienia:

Najlepsze praktyki dostrajania wydajności obciążeń wrażliwych na opóźnienia w maszynach wirtualnych vSphere

Tutaj zaznaczyłem ustawienia zastosowane w naszym systemie kolorem żółtym:

Myślę, że ustawienia, które miały największy wpływ, to konfiguracja liczb i ustawienie wysokiej czułości na opóźnienia . Które oba wymagały jawnego przydzielania / rezerwowania fizycznych rdzeni procesora i pamięci RAM dla maszyny wirtualnej.

Dodaliśmy także więcej rdzeni do maszyny wirtualnej i teraz musimy zaktualizować naszą licencję SQL Server ze Standardowej na Enterprise.

Wygląda na to, że system Windows zgłasza częstotliwość taktowania twoich rdzeni procesora 4,6 Ghz jako 2,6 Ghz ... Uruchomiłbym narzędzie takie jak CPU-Z, aby sprawdzić, na jakiej prędkości faktycznie pracują, a następnie spojrzeć na zmianę ustawień zasilania w zarówno Windows, jak i BIOS / Management OS, aby wyłączyć wszelkie ustawienia oszczędzania energii, które mogą zmniejszać szybkość rdzeni.