Niedawno uwzględniono uruchamianie programu SQL Server Trace Flag 8048, aby rozwiązać poważny problem rywalizacji o blokadę w systemie SQL Server 2008 R2.
Zainteresowany wiadomościami od innych, którzy znaleźli przypadki użycia, w których wartość wydajności została dostarczona przez flagę śledzenia 8048 (promuj strategię przyznawania pamięci zapytań od węzła NUMA do rdzenia), flagę śledzenia 8015 (SQL Server ignoruje fizyczną NUMA) lub SUMA ( przeplatał dostatecznie jednolity dostęp do pamięci, opcja BIOS-u na niektórych maszynach NUMA).
Flaga śledzenia 8048 http://blogs.msdn.com/b/psssql/archive/2011/09/01/sql-server-2008-2008-r2-on-newer-machines-with-more-than-8-cpus -presented-per-numa-node-may-need-trace-flag-8048.aspx
Flaga śledzenia 8015 http://blogs.msdn.com/b/psssql/archive/2010/04/02/how-it-works-soft-numa-io-completion-thread-lazy-writer-workers-and-memory -nodes.aspx
Krwawe szczegóły obciążenia systemu, zebrane dane z niesprawnego systemu i zebrane dane z systemu po interwencji.
Flaga śledzenia 8048 była „poprawką”, ale czy była to najlepsza poprawka? Czy SQL Server ignorując fizyczną NUMA z powodu flagi śledzenia 8015 osiągnąłby to samo? Co z ustawieniem BIOS-u do przeplatania pamięci, pozostawiając serwerowi zachowanie SUMA imitujące SMP zamiast zachowania NUMA?
Pokój! tw: @sql_handle
Informacje o systemie: - 4-rdzeniowy sześciokątny Xeon E7540 @ 2,00 GHz, hyperthreaded - 128 GB RAM - WS2008R2 - MSSQL 2008 R2 SP2 - maxdop 6
O obciążeniu pracą: - 1000s zaplanowanych / ustawionych w kolejce raportów Batch napędzanych z 2 serwerów aplikacji raportów. - 3 warianty partii: codziennie, co tydzień, co miesiąc - Wszystkie połączenia serwerów aplikacji raportów z programem SQL Server są tworzone jako pojedyncze konto usługi - Maksymalna współbieżność raportu = 90
Kluczowe ustalenia dotyczące problematycznego systemu: - Z Perfmon, 15-sekundowe interwały - - System pozostaje w 95% -100% zajęty procesorem - - Wyszukiwania stron bufora SQL Server <10000 na sekundę
- Od oczekiwania i blokowania DMV, 5-minutowe odstępy
- Wysokie kelnerzy CMEMTHREAD i czas oczekiwania
- Wysokie obroty SOS_SUSPEND_QUEUE i wycofania
Wpis inżyniera CSS Boba Dorra na temat flagi śledzenia 8048 wskazuje, że systemy z więcej niż 8 rdzeniami na węzeł NUMA mogą mieć podobne objawy z powodu wąskiego gardła w przyznawaniu pamięci zapytań. Flaga śledzenia 8048 zmieni strategię na rdzeń zamiast na węzeł NUMA.
Interwencja
MSSQL został zrestartowany z -T8048 na miejscu. Różnica była natychmiast widoczna: współczynnik wyszukiwania stron bufora wzrósł o ponad 1 milion i wzrósł do 8 milionów na sekundę. Problematyczne zadanie wsadowe, które wcześniej nie mogło zostać ukończone w ciągu 24 godzin, zakończyło się w mniej niż 4 godziny. Kolejne obciążenie wsadowe, które nie było przedmiotem dochodzenia ani interwencji, zostało przedstawione w ramach walidacji wartości korekcyjnej flagi śledzenia 8048 (i upewnienia się, że jej niepożądane skutki uboczne były minimalne). Partia raportu wcześniej ukończona w ciągu 2 godzin; z flagą śledzenia 8048 na miejscu partia raportu została ukończona w około 20 minut.
Nightly ETL również napotkało korzyść. Czas ETL spadł z około 60 minut do 40 minut.
Gromadząc informacje z kilku miejsc, spekuluję, że wysoki stopień kolejkowania raportów, liczba raportów równoczesnych jest większa niż liczba wątków sprzętowych, a konto jednego użytkownika dla wszystkich raportów łącznie, aby wywrzeć presję na jednym węźle NUMA, dopóki nacisk wątku roboczego nie spowoduje nie będzie przychylnie nastawiony do następnego żądania połączenia przychodzącego dla tego samego konta użytkownika, w którym to momencie następny węzeł NUMA natychmiast uzyska pewną liczbę połączeń. Każdy węzeł NUMA miałby duże prawdopodobieństwo podkreślenia wąskiego gardła przyznania pamięci zapytania.
Otwarcie kolejnych linii dla przyznania pamięci zapytań usunęło wąskie gardło. Ale nie jestem pewien kosztów. Post CSS Boba Dorra wyjaśnia, że istnieje dodatkowy narzut pamięci z flagą śledzenia 8048. Czy to narzut w obrębie obszaru alokacji pojedynczej strony zarządzanego przez maksymalną pamięć serwera MSSQL 2008 R2? Jeśli tak, to sądzę, że system będzie po prostu miał o kilka stron mniej bazy danych w pamięci podręcznej puli buforów. Jeśli nie, to czy należy zmniejszyć maksymalną pamięć serwera, aby pomieścić?
źródło