W jaki sposób mogę dowiedzieć się, co działa na moim serwerze SQL?

Mój procesor SQL Server był na około 90% przez większość dnia.

Nie jestem w stanie go ponownie uruchomić, ponieważ jest w ciągłym użyciu.

Czy można dowiedzieć się, co w SQL powoduje takie przeciążenie procesora?

Mam uruchomiony SQL Profiler, ale tak wiele się dzieje, że trudno powiedzieć, czy coś w szczególności jest przyczyną.

Uruchomiłem sp_who2, ale nie jestem pewien, co wszystko dokładnie oznacza i czy można zidentyfikować możliwe problemy tutaj.

Aby uprzedzić wszelkie odpowiedzi "prawdopodobnie jest po prostu używane dużo", to dopiero dzisiaj kopnął z zupełnie normalnego poziomu aktywności.

Szukam sposobu na znalezienie tego, co powoduje smutek CPU w SQL.

Author: gbn, 2009-06-03
Source

5 answers

Zakładam tutaj z należytą starannością, że potwierdziłeś, że procesor jest faktycznie zużywany przez proces SQL(liczniki kategorii procesów perfmon potwierdziłyby to). Zwykle w takich przypadkach pobiera się próbkę odpowiednich liczników wydajności i porównuje je z linią bazową ustaloną w normalnych warunkach pracy przy obciążeniu. Po rozwiązaniu tego problemu zalecam ustalenie takiej podstawy dla przyszłych porównań.

Możesz znaleźć dokładnie, gdzie SQL spędza każdy procesor cykl. Ale wiedząc, gdzie szukać wymaga dużo wiedzy i doświadczenia. Czy SQL 2005/2008 czy 2000 ? Na szczęście dla 2005 i nowszych istnieje kilka rozwiązań z półki. Masz już kilka dobrych wskazówek z odpowiedzią Johna Samsona. Chciałbym dodać zalecenie, aby pobrać i zainstalować raporty SQL Server Performance Dashboard . Niektóre z tych raportów obejmują najważniejsze zapytania według czasu lub we / wy, najczęściej używane pliki danych i tak dalej. problem w tym. Wyjście jest zarówno Numeryczne, jak i graficzne, więc jest bardziej przydatne dla początkujących.

Zalecałbym również użycie skryptuAdama ' s Who is Active , choć jest to nieco bardziej zaawansowane.

I na koniec polecam pobrać i przeczytać białą księgę MS SQL Customer Advisory Team na temat analizy wydajności: SQL 2005 Waits and Queues .

Moim zaleceniem jest również spojrzenie na I / O. jeśli dodałeś load do serwera, który kasuje bufor basen (tj. potrzebuje tak dużo danych, że usuwa z pamięci buforowane strony danych) rezultatem byłby znaczny wzrost CPU (brzmi zaskakująco, ale to prawda). Winowajcą jest zwykle nowe zapytanie, które skanuje dużą tabelę od końca do końca.

 26
Author: Remus Rusanu,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-11-15 06:28:25

To zapytanie wykorzystuje DMV do identyfikacji najbardziej kosztownych zapytań przez CPU 

SELECT TOP 20
    qs.sql_handle,
    qs.execution_count,
    qs.total_worker_time AS Total_CPU,
    total_CPU_inSeconds = --Converted from microseconds
        qs.total_worker_time/1000000,
    average_CPU_inSeconds = --Converted from microseconds
        (qs.total_worker_time/1000000) / qs.execution_count,
    qs.total_elapsed_time,
    total_elapsed_time_inSeconds = --Converted from microseconds
        qs.total_elapsed_time/1000000,
    st.text,
    qp.query_plan
FROM
    sys.dm_exec_query_stats AS qs
CROSS APPLY 
    sys.dm_exec_sql_text(qs.sql_handle) AS st
CROSS APPLY
    sys.dm_exec_query_plan (qs.plan_handle) AS qp
ORDER BY 
    qs.total_worker_time DESC

Aby uzyskać pełne wyjaśnienie Zobacz: Jak zidentyfikować najbardziej kosztowne zapytania SQL Server przez CPU

 85
Author: John Sansom,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-01-27 13:07:28

Uruchom którąś z nich w odległości kilku sekund. Wykryjesz wysokie połączenie procesora. Or: stored CPU in a local variable, WAITFOR DELAY, compare stored and current CPU values 

select * from master..sysprocesses
where status = 'runnable' --comment this out
order by CPU
desc

select * from master..sysprocesses
order by CPU
desc

Może nie jest najbardziej elegancki, ale skuteczny i szybki.

 5
Author: gbn,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-06-03 14:29:11

Możesz uruchomić SQL Profiler i filtrować według PROCESORA lub czasu trwania, aby wykluczyć wszystkie "małe rzeczy". Wtedy powinno być o wiele łatwiej określić, czy masz problem, taki jak konkretny przechowywany proc, który działa znacznie dłużej niż powinien (może to być brakujący indeks lub coś takiego).

Dwa zastrzeżenia:

  • jeśli problemem są ogromne ilości małych transakcji, to filtr, który opisałem powyżej, wykluczy je i przegapiłbyś to.
  • również, jeśli problem jest pojedyncze, masywne zadanie (takie jak 8-godzinne zadanie analizy lub źle zaprojektowane select, które musi połączyć miliard wierszy) może nie być widoczne w profilerze, dopóki nie zostanie całkowicie wykonane, w zależności od tego, jakie zdarzenia profilujesz (SP:completed vs sp:statementcompleted).

Ale normalnie zaczynam od Monitora aktywności lub sp_who2.

 5
Author: BradC,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-06-03 14:58:52

Dla podejścia GUI chciałbym spojrzeć na Monitor aktywności pod zarządzanie i sortuj według procesora.

 3
Author: cmsjr,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-06-03 14:40:33