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

21

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

uchwyt sql
źródło

Odpowiedzi:

12

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
Jeremy Lowell
źródło
Dzięki za wzmiankę o sys.dm_os_nodes i sys.dm_os_waiting_tasks. Piszę wiele procedur przechowywanych w celu profilowania działania systemu, najpierw dążąc do nieco zoptymalizowanej linii bazowej, a następnie szukając odchyleń. W tej chwili przechwytywanie oczekiwań i obrotów, następnie nadchodzą przydziały pamięci (w tym dop na pamięć) ... kolejne indywidualne kelnerzy i węzły, jak omówiono ... potem może do urzędników pamięci i liczników pamięci podręcznej ...
sql_handle
1
Innym interesującym licznikiem do obejrzenia jest perfmon: SQLServer: Węzeł bufora :. Liczniki w tej rodzinie zainteresowań to Strony obce, Strony bezpłatne, Długość życia strony, Strony ogółem, Strony docelowe i Strony skradzione. Zgaduję, że zanim zaimplementowałeś flagę śledzenia, masz bardzo dużą liczbę stron zagranicznych - Czy masz włączony TF 834? Jeśli tak, to odkryłem, że nie przydziela pamięci do każdego węzła numa w sposób zrównoważony, co prowadzi do bardzo dużej liczby kosztownych wyszukiwań w pamięci zdalnego węzła numa. System, w którym miałem ten problem, zawierał w tym czasie 1 TB pamięci RAM.
Jeremy Lowell,
słuszne uwagi. Obserwowałem wskaźniki węzła buforowego. Najbardziej dziwne było to, że początkowo węzeł 00 nie miał obcych stron, podczas gdy inne węzły miały ogromne liczby. Myślę, że było to spowodowane tym, że nasz ETL przeprowadzał zwiększenie bufora z wystarczająco niską liczbą wątków, aby całkowicie zmieścić się w węźle buforowym / węźle NUMA 00. Nie mamy włączonej flagi śledzenia 834, ale wkrótce zaczniemy z nią testować. Nasze testy obciążenia na Linux Oracle 11gR2 wykazały wielką korzyść dla dużych stron pamięci, myślę, że zobaczymy zyski w Windows dzięki SQL Server.
sql_handle
@ Mike Soft NUMA vs. TF 8048. Myślę, że soft NUMA pozwoliłby mi tworzyć „węzły pamięci” w obrębie węzłów NUMA. Więc jeśli stworzyłem miękką NUMA dla każdego rdzenia, byłyby (być może) 24 linie dla wniosków o przyznanie pamięci zapytań. Ale może też 24 węzły pamięci? Martwiłbym się trochę narzutem w zarządzaniu 24 węzłami pamięci, z których każdy rdzeń tworzy „obce” odwołania do stron za każdym razem, gdy przekracza miękką granicę NUMA, i naprawdę obce odniesienia, gdy przekracza granicę, aby odwoływać się do strony, która jest inna miękkie NUMA i twarde NUMA. Majstruję i zobaczę, czy mogę coś rozpoznać.
sql_handle