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

22

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.

PaulJ
la source
1
Points pour une question approfondie, mais avez-vous considéré que 16 Go de RAM pourraient ne pas suffire pour 1200 bases de données?
Nick Vaccaro
Je ne peux pas vraiment aider dans le grand schéma des choses, mais je sais que MSSQL a été conçu pour consommer autant de RAM que possible. Cela a vraiment du sens car sinon, il y aurait de la RAM à gaspiller. Le fait qu'il passe à 15 Go peu de temps après le redémarrage n'est pas vraiment un problème en soi, je ne pense pas. Cependant, @Norla pourrait avoir raison de dire que le 16 n'est tout simplement pas suffisant pour ce que vous voulez faire.
Combien de SPID sont actifs pendant la lenteur? Exécutez sp_who2 et indiquez le nombre de lignes.
Nick Vaccaro
Juste vérification - Avez-vous des tâches de serveur SQL en cours d'exécution? Pourriez-vous les arrêter un par un pour voir si l'un d'entre eux est à l'origine de ce problème?
Quelle est la sortie de: sélectionnez SUM (single_pages_kb + multi_pages_kb) /1024.0 dans sys.dm_os_memory_clerks où [name] = 'TokenAndPermUserStore'
Mark Storey-Smith

Réponses:

7

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.

détroit de darin
la source
je suis d'accord, le comportement fait ressembler à une fuite de mémoire.
Nick Kavadias
+1 Pour fuite de mémoire. Je doute que l'espérance de vie des pages soit très longue sur ce serveur, mais cela ne devrait pas faire croître rapidement le fichier d'échange. Pour info, presque le même problème ici (c'était AV qui était le problème): social.msdn.microsoft.com/Forums/en/sqlsetupandupgrade/thread/…
brian
5

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).

StanleyJohns
la source
le 1200 n'est pas si mal! Le plus grand obstacle a été de surmonter les problèmes de pool de connexions, qui ont été résolus en définissant la chaîne de connexion sur master, puis sur USE [DBName] après la connexion. En termes de requête, j'ai exécuté select * from sys.dm_exec_requests où session_id> 50 et session_id <> @@ spid, et c'est une courte liste de 4 à 5 demandes, max, et ils laissent la liste dans les 500 ms généralement. Mais je vais essayer une fois que nous aurons le ralentissement, il a été redémarré dimanche, alors maintenant, il fredonne comme d'habitude.
PaulJ
@PaulJ merci pour l'astuce sur la mise en commun des connexions. Je fais un peu de lecture là-dessus maintenant.
StanleyJohns
5

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
DForck42
la source
super truc, merci. Je l'ai réduit à 14 Go. J'ai appris quelque chose de nouveau ici, car j'avais toujours laissé SQL Server prendre ce qu'il voulait. Un autre bon article pour référence soutenant cela: sqlservercentral.com/blogs/glennberry/2009/10/29/…
PaulJ
4

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?

mrdenny
la source
3

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?

Shawn Melton
la source
la plus grande base de données est de 5 Go. Seulement 25 d'entre eux font 1 Go ou plus. La grande majorité est de 50 à 200 Mo.
PaulJ
"Exécutez-vous SSRS, SSIS ou SSAS sur le même serveur?" - Exécuter aucun de ces services. C'est une pure boîte sql.
PaulJ