SQL Server - ktoś używa SUMA, flagi śledzenia 8048 lub flagi śledzenia 8015?

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ć?

To jest świetny post.

Aby odpowiedzieć na ostatnie pytanie, spekuluję, że twoja odpowiedź brzmi „tak”.

To powiedziawszy, prawdopodobnie wybrałbym soft numa przed uciekaniem się do flag śladowych. Myślę, że masz rację co do alokacji węzłów numa i może to być przyczyna twojego problemu. Za pomocą soft numa można skalować żądania, w zależności od liczby numerów węzłów (4?) - do 4, jeśli jest to poprawna liczba, a następnie przypisać, za pomocą adresu IP, każdy host do określonego węzła numa, dodatkowo do tego wyłączyłbym hiperwątkowość. W sumie problem prawdopodobnie by się zmniejszył, jednak zrobiłby to kosztem mniejszej liczby planistów.

Na osobną myśl przyjrzałbym się parametryzacji wymuszonej - fakt, że obciążenie napędza procesor tak wysoko, jest bardzo interesujący i może warto się temu przyjrzeć.

Wreszcie, w systemach z wieloma liczbami węzłów, zazwyczaj następującą kwerendę zrzucam do tabeli co N sekund. Sprawia, że ​​można przeprowadzić interesującą analizę po wprowadzeniu zmian obciążenia lub flag śledzenia:

SELECT getdate() as poll_time, node_id, node_state_desc, memory_node_id, online_scheduler_count, active_worker_count, avg_load_balance, idle_scheduler_count
FROM sys.dm_os_nodes WITH (NOLOCK) 
WHERE node_state_desc <> N'ONLINE DAC'

i

SELECT top 10 getdate() as sample_poll, wait_type, count (*)
FROM sys.dm_os_waiting_tasks
WHERE [wait_type] NOT IN
('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK','SLEEP_SYSTEMTASK',
'SQLTRACE_BUFFER_FLUSH','WAITFOR', 'BROKER_TASK_STOP',
'BROKER_RECEIVE_WAITFOR', 'OLEDB','CLR_MANUAL_EVENT', 'CLR_AUTO_EVENT' ) 
GROUP BY wait_type
ORDER BY COUNT (*) DESC