web-dev-qa-db-fra.com

Comment puis-je savoir ce qui frappe ma SQL Server?

Mon processeur SQL Server a été à environ 90% pour la plupart des jours.

Je ne suis pas en mesure de pouvoir le redémarrer car il est constamment utilisé.

Est-il possible de savoir ce qui, dans SQL, cause une telle surcharge du processeur?

J'ai exécuté SQL Profiler mais il se passe tellement de choses qu'il est difficile de dire si quelque chose en particulier en est la cause.

J'ai exécuté sp_who2 mais je ne suis pas sûr de ce que tout signifie exactement et s'il est possible d'identifier les problèmes possibles ici.

Pour anticiper toute réponse "il est probable que l'on en utilise beaucoup", elle n'a été lancée aujourd'hui que par des niveaux d'activité parfaitement normaux.

Je suis après tout moyen de trouver ce qui cause un problème de processeur en SQL.

sql-serverperformancecpu-usage
59
joshcomley

Je suppose ici que vous avez confirmé que le processeur est réellement consommé par le processus SQL (les compteurs de la catégorie perfmon Process le confirmeraient). Normalement, dans de tels cas, vous prenez un échantillon des compteurs de performance pertinents et vous les comparez à une base que vous avez établie dans des conditions de fonctionnement de charge normales. Une fois que vous avez résolu ce problème, je vous recommande d’établir une telle base de référence pour les comparaisons futures.

Vous pouvez trouver exactement où SQL investit chaque cycle de la CPU. Mais savoir où chercher prend beaucoup de savoir-faire et d’expérience. Est-ce que SQL 2005/2008 ou 2000? Heureusement pour 2005 et les plus récents, il existe deux solutions prêtes à l'emploi. Vous avez déjà un bon pointeur avec la réponse de John Samson. Je voudrais ajouter une recommandation pour télécharger et installer le Rapports du tableau de bord de performance de SQL Server . Certains de ces rapports incluent les requêtes les plus fréquentes par heure ou par E/S, les fichiers de données les plus utilisés, etc., et vous pouvez rapidement avoir une idée du problème. Le résultat est à la fois numérique et graphique, il est donc plus utile pour un débutant.

Je vous recommanderais également d'utiliser le script Adam's Who is Active , bien que ce soit un peu plus avancé.

Enfin, je vous recommande de télécharger et de lire le livre blanc sur l’analyse des performances de l’équipe de conseil aux clients MS SQL: SQL 2005 Waits and Queues .

Ma recommandation est également de regarder I/O. Si vous ajoutez au serveur une charge qui supprime le pool de mémoire tampon (c.-à-d. Qu'il a besoin de suffisamment de données pour vider les pages de données en cache de la mémoire), il en résulterait une augmentation significative du processeur (un son surprenant, mais vrai). Le coupable est généralement une nouvelle requête qui analyse une grande table de bout en bout.

26
Remus Rusanu

Cette requête utilise des DMV pour identifier les requêtes les plus coûteuses par 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

Pour une explication complète, voir: Comment identifier les requêtes SQL Server les plus coûteuses par CP

90
John Sansom

Vous pouvez exécuter le Générateur de profils SQL et filtrer par processeur ou par durée afin d'exclure tous les "petits trucs". Ensuite, il devrait être beaucoup plus facile de déterminer si vous avez un problème comme un processus stocké spécifique qui s'exécute beaucoup plus longtemps que prévu (il pourrait s'agir d'un index manquant ou de quelque chose).

Deux mises en garde:

  • Si le problème concerne des quantités énormes de petites transactions, le filtre que je décris ci-dessus les exclut et vous rateriez ceci.
  • De plus, si le problème concerne un seul travail massif (comme un travail d'analyse de 8 heures ou un choix mal conçu qui doit joindre plusieurs milliards de lignes), il est possible que ce ne soit pas visible dans le profileur tant que le travail n'est pas complètement terminé. sur quels événements vous profilez (sp: terminé vs sp: déclaration terminée).

Mais normalement, je commence avec le moniteur d'activité ou sp_who2.

7
BradC

Exécutez l'un ou l'autre à quelques secondes d'intervalle. Vous allez détecter la connexion CPU élevée. Ou: CPU stockée dans une variable locale, WAITFOR DELAY, comparer les valeurs stockées et actuelles du CPU

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

select * from master..sysprocesses
order by CPU
desc

Peut-être pas le plus élégant mais efficace et rapide.

5
gbn

Pour une approche graphique, je jetterais un coup d’œil à Activity Monitor sous Management et trierais par CPU.

3
cmsjr

Vous pouvez trouver une requête utile ici:

Recherche de la cause du processeur élevé de SQL Server

Pour moi cela a beaucoup aidé:

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

Dans les champs status, wait_type et cpu_time, vous pouvez trouver la tâche la plus consommatrice de cpu en cours d’exécution.

3
Saadat