Troubleshooting Resource Governor

Jeśli nie klasyfikatora UDF dostępne dla klasyfikacji następnie wszystkie sesje automatycznie przejdzie do domyślnej grupa obciążenia.Po utworzeniu klasyfikatora UDF, należy sprawdzić, czy jest zarejestrowany z Resource Governor i aktualizacji konfiguracja w pamięci.

Tworzenie, rejestrowanie i Włączanie klasyfikatora UDF jest trzech etapów:

• Najpierw należy utworzyć funkcja.

  CREATE FUNCTION function_name() RETURNS <something> 
  WITH SCHEMABINDING
  

• Po drugie należy zarejestrować funkcja z Resource Governor.

  ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION=schema_name.function_name)
  

• Po trzecie musisz zaktualizować konfiguracja Resource Governor w pamięci.

  ALTER RESOURCE GOVERNOR RECONFIGURE
  

Po pierwsze, należy podczas rozwiązywania problemów z klasyfikacji jest Sprawdź, czy funkcja utworzony jest zarejestrowane Resource Governor i konfiguracja został zaktualizowany.Uzyskaj nazwę schematu za pomocą następującej kwerendy (schema_name) i nazwę funkcja klasyfikatora (function_name) klasyfikatora UDF, którego używa obecnie Resource Governor.

USE master
SELECT 
      object_schema_name(classifier_function_id) AS [schema_name],
      object_name(classifier_function_id) AS [function_name]
FROM sys.dm_resource_governor_configuration

Można użyć poprzedniego podejścia rozwiązywać scenariusz, w którym zmienione klasyfikatora UDF, ale Resource Governor programu poprzedniego logiki funkcja do klasyfikowania sesje.To zachowanie oznacza, wprowadzone zmiany nie zostały zastosowane do konfiguracja w pamięci.

Można utworzyć funkcja bardzo skomplikowane klasyfikatora nie dawać oczekiwanych wyniki lub znacznych zasób.Po zdefiniowaniu podstawowych procedur rozwiązywania problemów należy następnie sprawdź, czy funkcja logiki dźwięku.Najgorszy scenariusz jest jednym flaw kodowania, w którym wyniki w nieskończonej pętli lub niekontrolowane zapytanie.

Dedykowane połączenia administratora (DAC) można użyć rozwiązywać źle napisane funkcja klasyfikatora, ponieważ DAC nie podlega klasyfikacji i mogą być używane podczas Resource Governor jest uruchomiony i klasyfikowania sesje przychodzące.Aby uzyskać więcej informacji, zobacz Za pomocą dedykowanego połączenia administracyjnego.

Można uzyskać informacje dotyczące funkcja klasyfikatora przez następujące badania:

• sys.dm_exec_query_stats.(contains statement information but not the actual function)

• sys.dm_exec_sql_text(używać w połączeniu z sql_handle z sys.dm_exec_query_stats)

• PreConnect:Starting Event Class (zawiera identyfikator i nazwę funkcja klasyfikatora)

W tym scenariuszu użytkownik zgłasza obniżenie wydajności i podejrzewasz, że licznik żądania jest redukowana.

Po pierwsze, należy wykonać jest sprawdzenie, czy ograniczanie liczby żądań jest jawnie skonfigurowane grupy, który użytkownik jest w.W tym celu sprawdzania członkostwa grupy użytkownika, aby sprawdzić, czy ustawienie GROUP_MAX_REQUESTS jest włączone.Jeśli GROUP_MAX_REQUESTS nie jest włączone, jest licznik nie wyraźnego żądania ograniczania.Należy zbadać dalsze, wykonując następujące czynności.

• Kwerenda sys.dm_os_waiting_tasks Aby zobaczyć, jeśli wszystkie żądania oczekują na typu oczekiwania RESMGR_THROTTLED.Obecność tego typu oczekiwania wskazuje ograniczania liczby żądań.

• Uruchom Monitor wydajności i zbieranie danych przy użyciu żądania kolejkowane i żądania Active liczników.Różna od zera żądania kolejkowane licznik wskazuje ograniczanie żądania.

• Sprawdź, czy żądania Active wartość odpowiada ustawienie GROUP_MAX_REQUESTS.Jeśli żądania Active wartość jest wyższa niż ustawienie GROUP_MAX_REQUESTS, grupa może mieć żądań, które nie ograniczono (na przykład otwartych transakcji).

• Jeśli żądania kolejkowane wynosi zero, wyboru żądania Active wszystkich grup obciążenia udostępniania tego samego zasób puli, ponieważ puli zostały nadmiernie obciążony zbyt wielu żądań.

Jeśli zasada która jest napędzana przez regulator zasobów generowania zdarzeń można użyć zdarzenie, który jest generowany po osiągnięciu maksymalnego limitu Procesora.

W tym scenariuszu należy ustalić, czy maksymalny limit Procesora (REQUEST_MAX_CPU_TIME_SEC), skonfigurowany do wykrywania kwerenda, która używa zbyt dużo Procesora jest zbyt niska.

Następujące akcje pomaga sprawdzić ustawienie limitu Procesora.

• Rozpocznij sesja śledzenia SQL i zebrać Przekroczony próg CPU zdarzenie.Gdy żądanie użytkownika osiągnie maksymalny limit wykorzystania Procesora, serwer automatycznie generuje zdarzenie śledzenia SQL.Jeśli ustawienie jest zbyt niska, duża liczba tych zdarzeń zostanie wygenerowany.

• Uruchom Monitor wydajności i zbieranie danych przy użyciu Max żądania czas cpu (ms) licznika.Wartość tego licznika można użyć jako przewodnik dla ustawiania limitu właściwe dla grupa obciążenia.

W tym scenariuszu można podejrzewać, że przepustowość Procesora jest ograniczona, ponieważ % wykorzystania Procesora licznika wydajności jest bliska ustawienie zasobów Gubernator MAX_CPU_PERCENT.Następująca kwerenda zwraca wartość % wykorzystania Procesora dla wszystkich grup obciążenia i pule zasób dla wystąpienie programu SQL Server.

select * from sys.dm_os_performance_counters where counter_name = 'cpu usage %'

Aby uzyskać więcej informacji, zobacz sys.dm_os_performance_counters (języka Transact-SQL).

Można określić, czy przepustowość Procesora jest redukowana, wykonując następujące kontrole w systemie.

• Sprawdź serwer całkowite wykorzystanie Procesora.Obciążenia innej niż SQL Server jest obecnie aktywne, mogą wpływać na kwerendy, którego dotyczy problem.

• Sprawdź dystrybucji procesora między pulami zasób.Pula zasób może ograniczono, ponieważ innej puli ma wysoką wartość minimalną skonfigurowany dla procesora.Porównaj liczniki dla oczekiwanej (obliczony wykorzystanie Procesora) przeciwko rzeczywiste wykorzystanie Procesora.

• Sprawdź grupy obciążenia, przypisane w puli zasób.Obciążenia z innych grup obciążenie może mieć wpływ na użytkowników, które są udostępnianie tej samej puli.

• Sprawdź dystrybucji użycie Procesora przez pracownikom.Kwerendy, w analizowanym mogą być umieszczane na harmonogram, zawierający długo działającymi kwerendami.przypadek kwerendy ma być ograniczona, ale faktycznego wydania jest nierówny rozkład obciążenia między pracownikom.

• Sprawdź, czy możliwych przypadków, gdy obciążenie jest uzyskiwanie zablokowane przez innych sesji, a nie jest redukowana przez ustawienia Resource Governor.

• Sprawdź, czy liczba sesji aktualnie uruchomione kwerendy w systemie.Pofragmentowaniu liczbę jednoczesnych żądań nakaz SQL Server próbuje zapewnienia ich wszystkich otrzymują przynajmniej niektóre kwoty CPU czas aby uniknąć zablokowania Procesora.

W tym scenariuszu można podejrzewać, rozmiar pamięci dotacji powoduje spowolnienie kwerendy.

Resource Governor wymusza kwerendy maksymalny limit pamięci poprzez zmniejszenie dotacji pamięci tak dużej kwerendy można dopasowanie w ramach limitu.Kwerenda pobiera mniej niż 100% dotacji pamięci, może być konieczne spill dane tymczasowe i zapisuje je na dysku, która może mieć znaczącego wpływu na wydajność.

Należy określić procent dużych kwerend do zestaw odpowiednią kwerendę maksymalny limit rozmiaru.Następujące akcje pomogą określić najlepsze ustawienia:

• Kwerenda sys.dm_exec_query_memory_grants Aby sprawdzić bieżący stan pamięci dotacji.Ideal_memory_kb kolumna zawiera idealne kwotę na podstawie szacunku kardynalność.Requested_memory_kb kolumna zawiera kwotę pytaniem, które mogłyby zmniejszyć po osiągnięciu limitu maksymalnego kwerendy.Jeśli requested_memory_kb jest znacznie niższy niż ideal_memory_kb, a następnie kwerenda może mieć przechodzeniu często (zakładając, że szacunek Kardynalność jest poprawne).

• Uruchom Monitor wydajności i zbieranie danych przy użyciu Ograniczona pamięć dotacje/s licznika.Wartość tego licznika reprezentuje szybkość pamięci dotacji liczba mniejsza niż kwota idealne otrzymane po uderzanie żądanie maksymalny limit rozmiaru.Duże kwerendy może działać znacznie wolniej niż te z kwotą idealna, ponieważ muszą spill na dysku, aby pozostać w granicach pamięci.

Aby złagodzić pamięci udzielić problem, należy zwiększyć limit rozmiaru puli lub limit rozmiaru maksymalnego rozmiaru pamięci.

W tym scenariuszu kwerenda nie powiedzie się z powodu błędu limitu czasu dotacji w pamięci.

Całkowita liczba aktywnej pamięci udzielić żądania i limity pamięci określonej grupa obciążenia i definicji puli zasób może odgrywać rolę w pamięci dotacji przekroczenia limitu czasu.Jeśli pula pojedynczy zasób jest współużytkowany przez wielu grup zasobów, liczba kwerend współbieżnych w innych grupach może wpłynąć limity pamięci dotacji.

Następujące akcje pomogą określić najlepsze ustawienia puli zasób:

• Kwerenda sys.dm_exec_query_memory_grants Aby wyświetlić liczbę dotacji pamięci i oczekiwania kwerendy dla tej grupy i puli.

• Kwerenda sys.dm_exec_query_resource_semaphores Aby zobaczyć udzielone całkowitej pamięci i cele.

Jeśli użycie pamięci dotacji jest większa niż dostępna pamięć, następnie można rozważyć zwiększenie limitu rozmiaru puli zasób.

Kwerenda nie powiedzie się z błąd braku pamięci.

Podstawowych procedur rozwiązywania problemów

Zaawansowane rozwiązywanie problemów

W tym scenariuszu można podejrzewać, że kwerenda działa wolno z powodu planu kwerend warunkami panującymi.optymalizator kwerendy może generować planu kwerend warunkami panującymi, jeżeli nie uzyskuje wystarczająco dużo pamięci z powodu limitu braku pamięci w puli zasób.

Następujące akcje pomogą określić najlepsze ustawienia puli zasób:

• Pobieranie danych z optymalizacje kwerendy na sekundę licznik, aby sprawdzić, czy grupa obciążenia ma dużą liczbę skompiluje kwerendy.

• Pobieranie danych z warunkami panującymi planów/s licznik, aby zobaczyć, jeśli optymalizator kwerendy często produkujących warunkami panującymi planów.

Jeśli jeden z powyższych warunków, należy rozważyć zwiększenie limitu pamięci puli zasób.