MS SQL Server ralentit avec le temps?

Avez-vous vécu l'un des problèmes suivants et avez-vous trouvé une solution:

Une grande partie du back-end de notre site Web est MS SQL Server 2005. Chaque semaine ou deux semaines, le site commence à fonctionner plus lentement - et je vois des requêtes de plus en plus longues à terminer en SQL. J'ai une requête que j'aime utiliser:

USE master
select text,wait_time,blocking_session_id AS "Block",
percent_complete, * from sys.dm_exec_requests 
CROSS APPLY sys.dm_exec_sql_text(sql_handle)  AS s2 order by start_time asc

Ce qui est assez utile ... il donne un instantané de tout ce qui fonctionne à ce moment précis sur votre serveur SQL. Ce qui est bien, c'est que même si votre processeur est fixé à 100% pour une raison quelconque et que le moniteur d'activité refuse de se charger (je suis sûr que certains d'entre vous y ont été), cette requête revient toujours et vous pouvez voir quelle requête tue votre base de données.

Lorsque j'exécute ceci, ou le moniteur d'activité pendant les périodes où SQL a commencé à ralentir, je ne vois aucune requête spécifique à l'origine du problème - elles s'exécutent toutes plus lentement sur toute la ligne. Si je redémarre le service MS SQL, tout va bien, il accélère - pendant une semaine ou deux jusqu'à ce que cela se reproduise.

Rien à quoi je peux penser n'a changé, mais cela vient de commencer il y a quelques mois ... Des idées?

--Ajoutée

Veuillez noter que lorsque ce ralentissement de la base de données se produit, peu importe si nous obtenons 100 000 pages vues par heure (heure la plus occupée) ou 10 000 pages vues par heure (temps lent), toutes les requêtes prennent plus de temps que d'habitude. Le serveur n'est pas vraiment stressé - le CPU n'est pas élevé, l'utilisation du disque ne semble pas être hors de contrôle ... cela ressemble à une fragmentation d'index ou quelque chose du genre, mais cela ne semble pas être le Cas.

En ce qui concerne le collage des résultats de la requête que j'ai collée ci-dessus, je ne peux vraiment pas le faire. La requête ci-dessus répertorie la connexion de l'utilisateur effectuant la tâche, l'intégralité de la requête, etc., et je ne voudrais vraiment pas distribuer les noms de mes bases de données, tables, colonnes et les connexions en ligne:) ... I peut vous dire que les requêtes en cours d'exécution à ce moment-là sont des requêtes normales et standard pour notre site qui s'exécutent tout le temps, rien hors de la norme.

- 24 mars

Cela fait environ deux semaines depuis le dernier redémarrage. J'ai apporté plusieurs modifications: j'ai trouvé quelques requêtes où nous faisions un usage intensif de tables temporaires qui étaient totalement inutiles et ont demandé à nos développeurs de changer la façon dont ils le faisaient. J'ai ajusté la taille de certaines des bases de données en croissance constante (lente mais sûre) à une taille intelligente pour leur croissance. J'ai également ajusté les paramètres de croissance automatique pour tout pour être plus intelligent (ils étaient tous définis sur une croissance de 1 Mo). Enfin, j'ai un peu nettoyé MSDB. Nous faisons des expéditions de journaux et nous n'avions vraiment pas besoin de conserver des années et des années de points de sauvegarde, j'ai écrit quelques scripts qui ne limitent cela qu'à quelques mois. Je continuerai à mettre à jour ce fil, car il est trop tôt pour dire si le problème est encore résolu.

Nous l'avons trouvé. Il s'est avéré que c'était en fait un serveur Web qui avait un problème avec l'un de ses pools d'applications. Il resterait bloqué en exécutant le même ensemble de requêtes encore et encore (ce qui arrivait dans les tables temporaires). Cela ferait juste une boucle et une boucle et finirait par rendre le serveur SQL triste. Une fois que ce pool de machines / applications incriminé a été trouvé et «déposé», tout a été résolu.

Vous devez vous demander, que se passe-t-il lors d'un redémarrage du service SQL? Beaucoup de choses, mais deux points pertinents me viennent à l'esprit:

1) La mémoire SQL est libérée.

Il est possible (pas sûr de la probabilité) que si votre paramètre MaxMemory est trop élevé, que le service SQL se développe pour utiliser toute la mémoire disponible et que Windows commence à échanger des éléments importants vers le fichier d'échange. Vérifiez que MaxMemory est défini sur une valeur raisonnable, laissant suffisamment de mémoire supplémentaire pour tout ce qui doit être exécuté sur cette boîte (s'agit-il d'un serveur SQL dédié? Ou s'agit-il également du serveur d'application?)

2) TempDB est reconstruit à partir des tailles par défaut.

Vérifiez vos tailles de fichier tempdb par défaut, en particulier la taille par défaut et l'intervalle de croissance du fichier journal TempDB. Si l'intervalle de croissance est trop faible, le journal peut créer une incroyable fragmentation interne, ce qui peut considérablement ralentir l'utilisation normale. Voir ces deux excellents articles de blog de Kimberly Tripp.

Faites-vous un usage intensif de tables ou de curseurs temporaires? Vérifiez que tous les curseurs sont fermés et désalloués correctement. Faites également attention aux serveurs liés - nous devons utiliser un pilote de bug pour un ancien serveur Informix lié et cela signifie périodiquement que nous devons redémarrer le serveur.

Si ça a l'air bizarre, cherchez le bizarre.

Si l'ajustement des paramètres du serveur SQL n'aide pas à essayer le gestionnaire de tâches Windows: allez dans l'onglet Processus, puis Options> Colonnes> Ajouter le temps CPU, les poignées, la lecture, l'écriture, d'autres et les options de mémoire.

Revenez à la liste des processus. Pour chaque colonne, triez par ordre décroissant et examinez les 5 premiers processus. Quelque chose qui sort de l'ordinaire? Par exemple, une fuite de mémoire sur un processus aura un nombre bizarre de poignées. Nous avons des imprimantes * ki qui ajoutent une poignée au processus DCSLoader toutes les 2 secondes. Après quelques semaines, une machine répertorie beaucoup de mémoire libre et de CPU, mais un processus avec 100 000 poignées et déplace à peine le pointeur de la souris.

Vérifiez également votre liste de tâches planifiées. Dites à votre AV de ne pas numériser les fichiers .mdf.

Dave,

Avez-vous vérifié les statistiques d'attente? la requête que vous avez donnée ci-dessus répertorie la colonne "last_wait_type". cette colonne peut avoir quelques détails concernant ce que les requêtes attendent (réseau, cpu, etc.)

Si votre «modèle de récupération» de sauvegarde est PLEIN, la prise de sauvegarde de la base de données puis la sauvegarde des journaux de transactions améliorent-elles les choses? Sur un système qui manque d'espace disque, ce genre de chose pourrait expliquer le problème.

Je semble avoir une configuration très similaire à la vôtre (16 Go, mise à niveau vers 32 Go et MD1000 avec un téraoctet de disques, double quadcore xeon).

La seule chose qui m'a aidé à diagnostiquer des problèmes bizarres comme celui-là dans le passé est beta_lockinfo par Erland Sommarskog. Exécutez-le lorsque le temps est lent et comparez.

J'ai également eu énormément de problèmes avec SQL 2005 avant SP2, mais SP3 est vraiment stable.

J'espère que cela donne des informations plus utiles:

SELECT  D.text SQLStatement,
        A.Session_ID SPID,
        C.BlkBy,
        ISNULL(B.status, A.status) Status,
        A.login_name Login,
        A.host_name HostName,
        DB_NAME(B.Database_ID) DBName,
        B.command,
        ISNULL(B.cpu_time, A.cpu_time) CPUTime,
        ISNULL((B.reads + B.writes), (A.reads + A.writes)) DiskIO,
        A.last_request_start_time LastBatch,
        A.program_name
FROM    sys.dm_exec_sessions A
        LEFT JOIN sys.dm_exec_requests B
        ON A.session_id = B.session_id
        LEFT JOIN (
                   SELECT   A.request_session_id SPID,
                            B.blocking_session_id BlkBy
                   FROM     sys.dm_tran_locks AS A
                            INNER JOIN sys.dm_os_waiting_tasks AS B
                            ON A.lock_owner_address = B.resource_address
                  ) C
        ON A.Session_ID = C.SPID
        OUTER APPLY sys.dm_exec_sql_text(sql_handle) D
WHERE   DB_NAME(B.Database_ID) = 'YourDBName' -- Comment out line for all db's
ORDER BY ISNULL(B.cpu_time, A.cpu_time) + ISNULL((B.reads + B.writes), (A.reads + A.writes)) DESC

Assurez-vous que db est d'accord avec:

DBCC CHECKDB -- Checks the allocation and structural integrity of all the objects in the specified database.
DBCC UPDATEUSAGE (bybox) -- Reports and corrects pages and row count inaccuracies in the catalog views

Gardez un œil sur l'espace journal avec:

DBCC SQLPERF(LOGSPACE)

Si vous voyez une expansion en cours, cela ralentira définitivement les choses. Si vous exécutez cela, vous verrez votre espace journal de plus en plus proche de 100%, puis le journal augmentera et le pourcentage diminuera à mesure qu'il aura de l'espace. J'espère que vous ne pourrez jamais le voir se développer avant que votre sauvegarde ne démarre et n'efface le journal.

Configuration principalement idiote. Arrive.

• Tout d'abord, vous devez en fait exécuter régulièrement la défragmentation d'index lors d'une maintenance. Planifiez-le en tant qu'activité, juste avant ou après avoir effectué des sauvegardes.

• Deuxièmement, ne développez pas automatiquement votre base de données et surtout ne la rétrécissez pas automatiquement. Selon la charge, la croissance automatique / rétrécissement automatique sont essentiellement des paramètres de suicide.

Pas vu un ralentissement de SQL Server comme ça à peu près jamais. Pouvez-vous publier les résultats de cette requête en période de stress intense? Bien sûr, rien ne vous empêche de surcharger SQL Server à ce moment-là?