Pourquoi des redémarrages périodiques sont-ils nécessaires pour assurer le bon fonctionnement de mon instance?

Nous avons un serveur de base de données de production sur SQL 2005. Tout fonctionne normalement pendant un certain temps, mais après quelques semaines, nous constatons une baisse notable des performances. Seul le redémarrage de SQL Server ramène les performances à la normale.

Quelques antécédents:

• Exécution de plus de 1 200 bases de données (principalement un seul locataire, certains multi-locataires). Avant que quiconque ne parle de déménager vers un multi-locataire, il y a des raisons valables de conserver cette structure ......
• La RAM est de 16 Go. Après le redémarrage, il ne faut pas trop de temps à SQL Server pour revenir à une utilisation de 15 Go.
• Les connexions de base de données actives représentent environ 80 connexions - ce qui nous semble assez sain étant donné qu'il existe un pool de connexions par serveur Web et par processus - nous n'avons donc pas de problème de fuite de connexion.

Nous avons essayé plusieurs choses en dehors des heures de pointe: - Exécutez DBCC DROPCLEANBUFFERS (avec un CHECKPOINT) pour vider le cache de données. Il n'a aucun effet et n'efface aucune utilisation de la RAM). - Exécutez FREEPROCCACHE et FREESYSTEMCACHE pour effacer les plans de requête et le cache de proc stocké. Aucun effet.

De toute évidence, le redémarrage de SQL Server n'est pas idéal dans un environnement de production actif. Il nous manque quelque chose. Quelqu'un d'autre a vécu ça?

MISE À JOUR: 28 avril 2012 Toujours aux prises avec ce problème. J'ai réduit la mémoire de SQL Server à 10 Go, juste pour exclure tout conflit avec le système d'exploitation. Je me rapproche de le réduire, mais j'ai besoin d'aide pour ma prochaine étape.

Voici ce que j'ai trouvé, après le redémarrage de SQL Server, le fichier d'échange oscille entre 12,3 Go et 12,5 Go. Il en sera ainsi pendant des jours. Le nombre total de threads de serveur passera entre 850 et 930 - également stable et cohérent pendant des jours (sqlserver se situe régulièrement entre 55 et 85 de ceux qui dépendent du trafic).

Ensuite, il y a "un événement". Je n'ai aucune idée de ce qu'est l'événement, je ne peux pas le voir dans les journaux, et je ne vois rien de cohérent le jour de la semaine ou l'heure à laquelle il se produit, mais tout le soudain fichier de page passe à 14.1 ou 14.2 Go, et les threads sautent entre 1750 et 1785.

En vérifiant les performances lorsque cela se produit, plus de 900 de ces threads sont sqlserver. Je vais donc sur sp_who2 pour voir d'où viennent ces threads ... et il n'y a que les 80 connexions db utilisées.

Alors ... est-ce que quelqu'un a des idées sur la façon de localiser le reste de ces 900 threads sur le serveur SQL et ce qu'ils font?

MISE À JOUR: 01 juin 2012 Toujours aux prises avec le problème. Pour tous ceux qui lisent encore ceci, le problème avec les fils sautant a été résolu. Cela était dû au logiciel de sauvegarde ComVault autodaté. Il créait un thread essayant de sauvegarder des bases de données qui n'étaient plus là (il maintenait une liste de bases de données précédentes) plutôt que de simplement sauvegarder les bases de données actuelles.

Mais - le problème persiste, et nous devons recommencer chaque semaine, donner ou prendre quelques jours. Travailler avec l'équipe Rackspace pour voir s'ils peuvent faire la lumière.

Vous dites que tout va bien, puis après quelques semaines, les performances chutent. (Habituellement, les gens affirment que les performances chutent rapidement, à des moments spécifiques ou à des intervalles apparemment aléatoires. Cela peut signifier de mauvaises performances d'E / S ou des tempêtes de verrous ou des requêtes gourmandes en CPU s'exécutant à des heures étranges, ou un travail planifié lourd ou un manque de indexation ou mauvaises statistiques provoquant des requêtes ou des lectures de disque gourmandes en CPU. Ou autre chose.) Les semaines sont inhabituelles.

Mon hypothèse est qu'une autre application sur votre serveur fuit de la mémoire. J'ai vu cela avec un logiciel antivirus (le méchant du logiciel serveur préféré de chaque DBA) et un logiciel de surveillance tiers. Je revérifierais l'utilisation de la mémoire de SQL Server, au fil du temps, et je saisirais également toute l'utilisation de la mémoire de toutes les autres applications sur la boîte. Si vous avez des limites strictes définies sur l'utilisation de la mémoire de SQL Server et si elle est définie pour ne pas autoriser la pagination, il se peut que d'autres applications soient paginées et consomment de la capacité d'E / S.

Ce n'est pas difficile à chercher. Si vous ne conservez pas déjà des mesures sur le serveur, je voudrais simplement lancer Perfmon et lui demander de prélever un échantillon toutes les 30 ou 60 minutes. Après quelques jours, vous pouvez voir une autre utilisation de la mémoire des applications augmenter.

Y a-t-il des messages d'erreur dans le journal SQL Server indiquant que «des parties importantes du serveur SQL ont été paginées»? Ce serait également un indice important.

Permettez-moi de vous féliciter d'avoir pu exécuter 1 200 bases de données sur une seule instance de SQL Server avec seulement 16 Go de RAM et de ne rencontrer ce type de problèmes qu'après quelques semaines de bon fonctionnement. Belle histoire à raconter au chapitre PASS local.

Maintenant, pour résoudre les problèmes: votre RAM est de 16 Go pour SQL et OS. Je suppose que votre paramètre de mémoire maximale est de 15 Go ou max. Cela pourrait provoquer l'utilisation du pool de mémoire tampon et étouffer le système d'exploitation. Vous dites que le nettoyage du pool de mémoire tampon et des caches ne montre aucune différence, plus votre PLE est supérieur à 300. Cela témoigne des goulots d'étranglement de la mémoire. Comment sont le CPU et les IO sur le serveur (spécifications / statistiques)?

Exécutez select * from sys.dm_exec_request where session_id>50 and session_id<>@@spidet quelles sont les affirmations de ressources que vous voyez (wait_type, wait_time, last_wait_type, wait_resource).

1200 bases de données, un os et peut-être d'autres choses? Oui, je pense que le serveur lui-même va avoir besoin de plus de 1 Go de RAM pour fonctionner, d'autant plus que si vous définissez 15 Go comme paramètre de mémoire maximale de SQL Server, il a toujours besoin de mémoire supplémentaire en dehors de ces 15 Go pour les threads.

Je ramènerais SQL Server à 14 Go pour donner au serveur un peu plus de marge de manœuvre.

En outre, un exemple donné dans «Internes et dépannage professionnels de SQL Server 2008» pour les allocations de mémoire sur un système SQL Server 2008 x64 avec un utilitaire de sauvegarde tiers avec 16 Go de RAM:

• 2 Go pour Windows
• 1 Go pour les threads de travail
• 1 Go pour les AMP, etc.
• 1 Go pour le programme de sauvegarde
• 11 Go pour SQL Server

Dans le livre, il montre comment déterminer le nombre maximum de threads que vous pouvez avoir et comment calculer la quantité de mémoire qu'ils prendront. Exécutez ceci (changez le type de serveur pour qu'il corresponde à votre serveur) pour déterminer la quantité de mémoire dont vos threads auront besoin.

declare @servertype int

set @servertype=1
/*
1: x86 (32-bit)
2: x64 (64-bit)
3: IA64

*/

select max_workers_count *
    (
        case @servertype when 1 then .5
            when 2 then 2
            when 3 then 4
            else .5
        end
    )
from sys.dm_os_sys_info

Si la mémoire de la base de données est répartie uniformément sur toutes les bases de données, vous ne disposez que de 12,8 Mo pour chaque base de données (15 * 1024) /1200=12,8. Vous avez besoin de plus de mémoire.

Vous devez voir pourquoi les performances ralentissent. Voyez-vous un verrouillage, un blocage, etc.? À quoi ressemblent les statistiques d'attente?

Les commandes DBCC vont uniquement effacer les tampons de mémoire, elles ne libéreront pas la mémoire sur le système d'exploitation.

Savez-vous que SQL Server consomme réellement de la mémoire? Je suggère de regarder la configuration de la session Perfmon ou de commencer à collecter des informations DMV après un redémarrage pour savoir ce que fait et travaille SQL Server. Notez également si les utilisateurs effectuent plus de travail que la normale pendant votre période de collecte (comme le traitement de fin de mois, etc.). Exécutez-vous SSRS, SSIS ou SSAS sur le même serveur?

Vous avez 1200 bases de données sur le système, quelle est la plus grande base de données dont vous disposez?