Jaka częstotliwość dotyczy wycieków mieszania / sortowania w tempdb?

Nasza aplikacja korporacyjna wykorzystuje SQL Server do przechowywania danych i jest przede wszystkim systemem OLTP. Jednak ważny składnik naszej aplikacji generuje znaczne obciążenie OLAP.

Nasze opóźnienie zapisu do tempdb wynosi około 100 ms. Ten trend utrzymuje się z czasem i ALLOW_SNAPSHOT_ISOLATIONjest wyłączony . Rozwiązujemy problem dotyczący tego problemu, a jedyną interesującą rzeczą, jaką do tej pory odkryliśmy, jest znaczna liczba wycieków mieszania i sortowania do tempdb. Przypuszczamy, że wynika to z obciążenia OLAP.

Pytanie

Jaka jest częstotliwość wycieków? Każdy? Ile wycieków / s? Nasze wstępne dane wskazują, że mamy około 2 wycieki mieszania na sekundę i 25 wycieków sortowania na minutę.

Czy to możliwe, że ta częstotliwość wycieków może być głównym winowajcą naszego opóźnienia zapisu w wysokiej tempdb?

Inne informacje

Używamy wielu plików dla tempdb zgodnie z zaleceniami dla liczby rdzeni. Pliki tempdb znajdują się w macierzy SAN RAID 1 + 0 (z wysokowydajnymi dyskami SSD), ale to samo urządzenie jak główne dane DB i pliki dziennika. Pliki tempdb mają wystarczająco duży rozmiar, aby rosły bardzo rzadko. Nie używamy flag śledzenia 1117 ani 1118. Inną zmienną jest to, że ta konfiguracja jest wspólna dla wielu różnych baz danych, z których wszystkie są obciążone od średniego do wysokiego.

Nasze opóźnienie zapisu wynoszące 100 ms jest znacznie większe niż dopuszczalne zakresy opóźnień zapisu tempdb, które znaleźliśmy w MSDN, umiejętnościach SQL i innych witrynach. Jednak opóźnienie zapisu w innych naszych bazach danych jest dobre (poniżej 10 ms). Na podstawie innych statystyk wydaje się, że intensywnie używamy tempdb, szczególnie w przypadku obiektów wewnętrznych. Wnikamy więc, aby dowiedzieć się, dlaczego nasza aplikacja tak intensywnie wykorzystuje obiekty wewnętrzne.

Rzeczywiste problemy z wydajnością na naszej platformie występują na różne sposoby. Monitorujemy liczniki perf, patrzymy na widoki DM i analizujemy zachowanie naszej aplikacji, aby spróbować zagłębić się w cechy wykorzystania zasobów w naszym systemie. Obecnie koncentrujemy się na wyciekach, ponieważ przeczytaliśmy, że wyciek ma drastyczny negatywny wpływ, ponieważ są wykonywane na dysku zamiast w pamięci. Wydaje się, że mamy bardzo dużą liczbę wycieków, ale chciałem uzyskać informacje na temat tego, co ludzie uważają za „wysoki”.

Czy to możliwe, że ta częstotliwość wycieków może być głównym winowajcą naszego opóźnienia zapisu w wysokiej tempdb?

Tak, jest to możliwe , choć zazwyczaj średnia wielkość wycieków i ich głębokość (tj. Rekurencyjne wycieki z mieszaniem, rodzaje wieloprzebiegowe) są ważniejsze niż częstotliwość jako taka.

SQL Server zapewnia szeroki zakres wskaźników i informacji DMV, które pomagają w rozwiązywaniu problemów z różnymi czynnikami wpływającymi na ciśnienie tempdb, z których wiele omówiono w artykule technicznym Microsoft „Praca z tempdb w SQL Server 2005” (dotyczy wszystkich wersji od 2005 r. ).

Powinieneś być w stanie skorzystać ze wskazówek i zapytań diagnostycznych zawartych w tym dokumencie, aby rozpocząć identyfikację głównych przyczyn ciśnienia tempdb. Nie lekceważ np. Aktywności magazynu wersji po prostu dlatego, że ALLOW_SNAPSHOT_ISOLATIONnie jest włączona. Wiele funkcji korzysta z magazynu wersji (np. Wyzwalacze, MARS, RCSI) oprócz izolacji migawek.

Jeśli wycieki sortowania i skrótu okażą się znaczące na wysokim poziomie, prawdopodobnie będziesz musiał ustawić dla tego określone monitorowanie. W zależności od wersji SQL Server nie zawsze jest to proste, jak można się spodziewać. Aby połączyć wycieki sortowania i mieszania z konkretnym zapytaniem, które je spowodowało, wymagane są powiadomienia o zdarzeniu lub zdarzenia rozszerzone. Artykuł SolidQ, „ Identyfikacja i rozwiązywanie ostrzeżeń dotyczących sortowania ” zawiera szczegółowe informacje i kilka dobrych ogólnych porad na temat rozwiązywania typowych przyczyn.

Powinieneś również współpracować z zespołem ds. Pamięci masowej, aby ustalić, ile dużego opóźnienia można przypisać do obciążenia, ile pochodzi z innych wspólnych zastosowań i jakie są opcje rekonfiguracji. Twoja analiza wskaźników SQL Server pomoże w dyskusji, podobnie jak wszelkie wskaźniki, które ludzie SAN są w stanie podać.