Mamy SQL Server 2008 R2 (10.50.1600) działający na wirtualnym serwerze Windows 2008 R2. Po aktualizacji procesora z 1 rdzenia na 4 i pamięci RAM z 4 gb na 10 gb zauważyliśmy, że wydajność jest gorsza.
Niektóre obserwacje, które widzę:
- Uruchomienie zapytania, które zajęło <5 sekund, zajmuje teraz> 200 sekund.
- Procesor jest przypisany do wartości 100, a przyczyną jest sqlservr.exe.
- Wybrana liczba (*) w tabeli z 4,6 mln wierszy zajęła ponad 90 sekund.
- Procesy uruchomione na serwerze nie uległy zmianie. Jedyną zmianą było zwiększenie procesora i pamięci RAM.
- Inne serwery SQL mają statyczny plik stronicowania, w którym ten serwer jest skonfigurowany do samodzielnego zarządzania nim.
Czy ktoś wcześniej napotkał ten problem?
Na sp_BlitzErik pobiegłem
EXEC dbo.sp_BlitzFirst @SinceStartup = 1;
Dając mi te wyniki.
Odpowiedzi:
Dużo się tu dzieje, a większość z nich jest dość szeroka i niejasna.
2008R2 RTM ukazało się 21 kwietnia 2010 r. Całkowicie nie ma wsparcia. Priorytetem będzie skorzystanie z najnowszego dodatku Service Pack, który ukazał się około 3 lata temu. W ten sposób będziesz chroniony, jeśli trafisz na dziwny błąd lub coś. Udaj się tutaj, aby dowiedzieć się, co musisz pobrać.
Ponieważ dodałeś vCPU (od 1 do 4) i nie zmieniłeś żadnych ustawień, twoje zapytania mogą teraz przebiegać równolegle. Wiem, że to brzmi, jakby wszyscy byli szybsi, ale poczekaj!
Być może dodałeś pamięć RAM, ale nie mogłeś zmienić Max Server Memory, aby Twój serwer mógł z niej skorzystać.
Dowiedz się, na co czeka Twój serwer. Projekt open source, nad którym pracuję, zapewnia bezpłatne skrypty, które pomogą Ci zmierzyć SQL Server. Udaj się tutaj, jeśli chcesz spróbować.
Będziesz chciał chwycić sp_BlitzFirst, aby sprawdzić statystyki czekania serwera. Możesz uruchomić go na kilka sposobów.
To pokaże ci, na co czekał Twój serwer od momentu uruchomienia.
EXEC dbo.sp_BlitzFirst @SinceStartup = 1;
To pokaże, na jakie zapytania czekają teraz, podczas 30-sekundowego okna.
EXEC dbo.sp_BlitzFirst @Seconds = 30, @ExpertMode = 1;
Gdy zorientujesz się, na jakie zapytania czekają (jest tam mnóstwo rzeczy o statystykach oczekiwania), możesz zacząć wprowadzać zmiany, aby uzyskać kontrolę.
Jeśli widzisz, że czekają
CXPACKET
, oznacza to, że twoje zapytania idą równolegle i być może nadepną. Jeśli trafisz w to, prawdopodobnie zechcesz rozważyć podwyższenie progu kosztu równoległości do 50, a może obniżenie MAXDOP do 2.Po tym kroku jest to, gdy chcesz użyć czegoś takiego jak sp_WhoIsActive lub sp_BlitzWho (ten ostatni znajduje się w repozytorium GitHub wcześniej), aby rozpocząć przechwytywanie planów zapytań. Oprócz statystyk czekania są jedną z najważniejszych rzeczy, na które możesz patrzeć, aby dowiedzieć się, co się dzieje.
Możesz także przeczytać ten artykuł Jonathana Kehayiasa na temat liczników VMWare, aby sprawdzić w związku z programem SQL Server.
Aktualizacja
Sprawdzanie statystyk oczekiwania i chłopca są dziwne. Z pewnością jest coś nie tak z procesorami. Twój serwer w większości siedzi znudzony, ale kiedy się nagrzewa, robi się źle. Spróbuję to łatwo zepsuć.
Jesteś uderzenie czekać trucizny o nazwie
THREADPOOL
. Nie masz jej mnóstwo, ale ma to sens, ponieważ twój serwer nie jest strasznie aktywny. Wyjaśnię dlaczego za minutę.Masz naprawdę długie średnie oczekiwania na
SOS_SCHEDULER_YIELD
iCXPACKET
. Jesteś na maszynie wirtualnej, więc musisz upewnić się, że SQL Server ma zastrzeżenia lub że pole nie jest strasznie nadmiernie subskrybowane. Hałaśliwy sąsiad może naprawdę zepsuć ci dzień tutaj. Będziesz także chciał się upewnić, że serwer / gość VM / host VM nie działa w trybie zrównoważonej energii. Powoduje to, że procesory obracają się do niepotrzebnie niskich prędkości i nie od razu wracają do pełnej prędkości.Jak się wiążą? Przy 4 procesorach masz 512 wątków roboczych. Pamiętaj, że masz tę samą ilość z jednym procesorem, ale teraz, gdy twoje zapytania mogą być równoległe, mogą zużywać o wiele więcej wątków roboczych. W twoim przypadku 4 wątki na równoległą gałąź zapytania równoległego.
Co dzieje się równolegle? Najprawdopodobniej wszystko. Domyślny próg kosztu dla równoległości wynosi 5. Liczba ta została ustalona jako domyślna pod koniec lat 90. XX wieku podczas pracy na komputerze wyglądającym tak .
To prawda, że Twój sprzęt jest mniejszy niż większość laptopów, ale wciąż jesteś o krok przed tym.
Kiedy pojawia się wiele równoległych zapytań, wyczerpują się wątki robocze. Kiedy tak się dzieje, zapytania po prostu czekają na wątki. Tam też
SOS_SCHEDULER_YIELD
pojawia się pytanie. Zapytania wychodzą z procesorów i nie wracają przez długi czas. Nie widzę żadnych blokujących oczekiwań, więc najprawdopodobniej po prostu wszyscy jesteście wypchani czekaniami na paralelizm wewnątrz zapytania.Co możesz zrobić?
sp_BlitzIndex
aby wyszukać brakujące żądania indeksu.Aby uzyskać dokładniejsze rozwiązywanie problemów, zapoznaj się z oficjalnym dokumentem, który napisałem dla Google na temat doboru sprzętu w chmurze.
Mam nadzieję że to pomoże!
źródło
Tak! Tego typu sytuacja wystąpiła w programie SQL Server vms w naszej farmie serwerów. Sprawdź czas gotowości procesora hosta VM i liczniki sterownika balonu pamięci. CZAS GOTOWOŚCI PROCESORA - BLOG CZĘŚĆ I i zrozumienie balonowania VMware Praca z moim sysadminem była kluczowa, ale nie była łatwa ...
źródło
Jedną z rzeczy, których nie zauważyłem, jest to, że dodanie vCPU do maszyny wirtualnej bardzo często może spowolnić ją z powodu planowania.
Podstawową ideą jest to, że jeśli maszyna wirtualna ma 4 jednostki vCPU, hiperwizor musi poczekać na dostępność 4 rdzeni fizycznych, aby zaplanować wszystkie jednostki vCPU, nawet jeśli 3 z nich są bezczynne.
Jeśli nie masz dużo rdzeni na hoście, a inne obciążenia są zajęte, może to spowodować dodatkowe oczekiwanie i znaczny spadek wydajności.
W VMware ESXi można to zobaczyć na zaawansowanych wykresach za pośrednictwem CPU Ready.
Oto jeden z wielu artykułów z prawdziwym przykładem tego, jak to się dzieje i jak zostało zdiagnozowane .
Dodanie większej ilości pamięci RAM może również spowodować nagły spadek wydajności, jeśli przydział pamięci RAM maszyny wirtualnej jest większy niż węzeł NUMA.
Ponadto konfiguracja procesorów vCPU (vSockets vs. vCores) może faktycznie wpływać na niektóre aplikacje, takie jak serwer SQL. Wynika to z faktu, że sam SQL Server jest świadomy NUMA (aby uniknąć tego samego rodzaju spadku wydajności obejmującego NUMA) i dlatego, że VMware może prezentować wirtualne węzły NUMA w różny sposób.
Jest to opisane w poście na blogu na własnej stronie VMware .
Biorąc to pod uwagę, cieszę się, że rozwiązałeś problemy z pomocą Erika, ale możesz chcieć spojrzeć i rozważyć te rzeczy.
źródło
Tylko mała pomoc (nie mogę tego dodać jako komentarza) kontynuując odpowiedź @ sp_BlitzErik, otrzymałem kilka zapytań z Pinalem i Maxem Vernonem (nie pamiętam gdzie), które mówią, ile MAXDOP powinieneś użyć:
-------------------------------------------------- -------
źródło
MAXDOP = 2
co jest zgodne z @sp_BlitzErik. Dzięki!