it-swarm.com.de

Wie finde ich heraus, was meinen SQL Server hämmert?

Meine SQL Server-CPU lag heute größtenteils bei etwa 90%.

Ich bin nicht in der Lage, es neu zu starten, da es ständig benutzt wird.

Ist es möglich herauszufinden, was in SQL eine solche CPU-Überlastung verursacht?

Ich habe SQL Profiler ausgeführt, aber es ist so viel los, dass es schwierig ist zu erkennen, ob irgendetwas speziell dafür verantwortlich ist.

Ich habe sp_who2 ausgeführt, bin mir aber nicht sicher, was alles genau bedeutet und ob es hier möglich ist, mögliche Probleme zu identifizieren.

Um zu verhindern, dass Antworten wie "Es wird wahrscheinlich nur häufig verwendet" angezeigt werden, ist dies heute nur noch von einem ganz normalen Aktivitätsniveau aus möglich.

Ich bin nach einer Möglichkeit zu finden, was CPU-Kummer in SQL verursacht.

59
joshcomley

Ich gehe hier von der gebotenen Sorgfalt aus, dass Sie bestätigt haben, dass die CPU tatsächlich vom SQL-Prozess belegt wird (Leistungsindikatoren für die Prozesskategorie würden dies bestätigen). Normalerweise entnehmen Sie für solche Fälle eine Stichprobe der relevanten Leistungsindikatoren und vergleichen sie mit einer Basislinie, die Sie unter normalen Lastbetriebsbedingungen ermittelt haben. Sobald Sie dieses Problem behoben haben, empfehlen wir Ihnen, eine solche Baseline für zukünftige Vergleiche zu erstellen.

Sie können genau feststellen, wo SQL in jedem einzelnen CPU-Zyklus ausgegeben wird. Aber zu wissen, wo sie suchen müssen, erfordert viel Know-how und Erfahrung. Ist SQL 2005/2008 oder 2000? Zum Glück gibt es ab 2005 einige Standardlösungen. Mit John Samsons Antwort haben Sie hier bereits ein paar gute Hinweise. Ich möchte eine Empfehlung zum Herunterladen und Installieren der SQL Server Performance Dashboard-Berichte hinzufügen. Einige dieser Berichte enthalten häufig gestellte Fragen nach Zeit oder E/A, die am häufigsten verwendeten Datendateien usw., und Sie können schnell ein Gefühl dafür bekommen, wo das Problem liegt. Die Ausgabe ist sowohl numerisch als auch grafisch, sodass sie für Anfänger nützlicher ist.

Ich würde auch empfehlen, Adams Who is Active-Skript zu verwenden, obwohl dies etwas fortgeschrittener ist.

Und zu guter Letzt empfehle ich Ihnen, das Whitepaper des MS SQL-Kundenberatungsteams zur Leistungsanalyse herunterzuladen und zu lesen: SQL 2005-Warteschlangen .

Meine Empfehlung ist auch, sich I/O anzuschauen. Wenn Sie dem Server eine Last hinzufügen, die den Pufferpool verwirft (dh so viele Daten benötigt, dass die zwischengespeicherten Datenseiten aus dem Speicher entfernt werden), führt dies zu einer signifikanten Erhöhung der CPU (klingt überraschend, ist aber wahr). Der Täter ist normalerweise eine neue Abfrage, die eine große Tabelle Ende-zu-Ende durchsucht.

26
Remus Rusanu

Diese Abfrage verwendet DMVs, um die teuersten Abfragen nach CPU zu identifizieren

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

Eine vollständige Erklärung finden Sie unter: Ermitteln der teuersten SQL Server-Abfragen nach CP

90
John Sansom

Sie können den SQL Profiler ausführen und nach CPU oder Dauer filtern, sodass Sie alle "kleinen Dinge" ausschließen. Dann sollte es viel einfacher sein, festzustellen, ob Sie ein Problem wie einen bestimmten gespeicherten Prozess haben, der viel länger als nötig ausgeführt wird (möglicherweise ein fehlender Index oder ähnliches).

Zwei Vorbehalte:

  • Wenn das Problem massive Mengen winziger Transaktionen sind, werden diese durch den oben beschriebenen Filter ausgeschlossen, und Sie würden dies verpassen.
  • Wenn es sich bei dem Problem um einen einzelnen, umfangreichen Job handelt (z. B. um einen 8-Stunden-Analysejob oder eine schlecht konzipierte Auswahl, bei der eine Milliarde Zeilen miteinander verknüpft werden müssen), wird dies möglicherweise erst dann im Profiler angezeigt, wenn der Vorgang vollständig abgeschlossen ist Zu welchen Ereignissen erstellen Sie ein Profil (sp: erledigt vs sp: Aussage erledigt).

Aber normalerweise beginne ich mit dem Activity Monitor oder sp_who2.

7
BradC

Führen Sie einen dieser Schritte einige Sekunden auseinander. Sie erkennen die hohe CPU-Verbindung. Oder: Gespeicherte CPU in einer lokalen Variablen, WAITFOR DELAY, vergleicht gespeicherte und aktuelle CPU-Werte

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

select * from master..sysprocesses
order by CPU
desc

Vielleicht nicht die eleganteste, aber effektiv und schnell.

5
gbn

Für einen GUI-Ansatz würde ich einen Blick auf Activity Monitor unter Management werfen und nach CPU sortieren.

3
cmsjr

Hier finden Sie einige nützliche Fragen:

ntersuchung der Ursache für eine hohe SQL Server-CP

Für mich hat das sehr geholfen:

SELECT s.session_id,
    r.status,
    r.blocking_session_id 'Blk by',
    r.wait_type,
    wait_resource,
    r.wait_time / (1000 * 60) 'Wait M',
    r.cpu_time,
    r.logical_reads,
    r.reads,
    r.writes,
    r.total_elapsed_time / (1000 * 60) 'Elaps M',
    Substring(st.TEXT,(r.statement_start_offset / 2) + 1,
    ((CASE r.statement_end_offset
WHEN -1
THEN Datalength(st.TEXT)
ELSE r.statement_end_offset
END - r.statement_start_offset) / 2) + 1) AS statement_text,
    Coalesce(Quotename(Db_name(st.dbid)) + N'.' + Quotename(Object_schema_name(st.objectid, st.dbid)) + N'.' +
    Quotename(Object_name(st.objectid, st.dbid)), '') AS command_text,
    r.command,
    s.login_name,
    s.Host_name,
    s.program_name,
    s.last_request_end_time,
    s.login_time,
    r.open_transaction_count
FROM sys.dm_exec_sessions AS s
    JOIN sys.dm_exec_requests AS r
ON r.session_id = s.session_id
    CROSS APPLY sys.Dm_exec_sql_text(r.sql_handle) AS st
WHERE r.session_id != @@SPID
ORDER BY r.cpu_time desc

In den Feldern status, wait_type und cpu_time finden Sie die Task mit dem höchsten CPU-Verbrauch, die gerade ausgeführt wird.

3
Saadat