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.