Comment puis-je déboguer un problème de tampon?
-
29-09-2020 - |
Question
J'ai une production "Microsoft SQL Server 2012 (SP1) - 11.0.3128.0 (X64)" qui montre des symptômes de tampon bizarre et d'espérance de vie de page (PLE).
J'exécute cette minute sur mon serveur (pour suivre ce problème):
SELECT @ple = CAST([cntr_value] AS VARCHAR(20))
FROM sys.dm_os_performance_counters
WHERE [object_name] LIKE '%Manager%'
AND [counter_name] = 'Page life expectancy'
SELECT @usedBufferPages = CAST(COUNT(*) /128 AS VARCHAR(20))
FROM sys.dm_os_buffer_descriptors
DECLARE @StartDate VARCHAR(8) = Convert(VARCHAR(8), GETDATE(), 14)
RAISERROR ('%s. PLE at %s and Used Buffers at %s at %s ', 0,
1,@runCountString ,@ple, @usedBufferPages, @StartDate) WITH NOWAIT
Ceci est un exemple de sortie:
16. PLE at 858 and Used Buffers at 7290 at 09:51:42 17. PLE at 918 and Used Buffers at 7342 at 09:52:42 18. PLE at 978 and Used Buffers at 7408 at 09:53:43 19. PLE at 1039 and Used Buffers at 7547 at 09:54:43 20. PLE at 1100 and Used Buffers at 7697 at 09:55:44 21. PLE at 1160 and Used Buffers at 7901 at 09:56:45 22. PLE at 1221 and Used Buffers at 7961 at 09:57:46 23. PLE at 1282 and Used Buffers at 8012 at 09:58:46 24. PLE at 11 and Used Buffers at 313 at 09:59:46 25. PLE at 31 and Used Buffers at 966 at 10:00:46 26. PLE at 90 and Used Buffers at 1580 at 10:01:47 27. PLE at 151 and Used Buffers at 3072 at 10:02:47 28. PLE at 211 and Used Buffers at 3152 at 10:03:47 29. PLE at 271 and Used Buffers at 3729 at 10:04:47
à l'élément n ° 24 SQL Server rapporte le PLE allant de 1 282 à 11 . SQL Server indique également que les tampons utilisés vont de
J'ai d'abord recherché des questions de fonctionnement médiocres et j'ai trouvé un peuple fixe (n'avait aucun effet sur la question). Mais, je ne trouve aucune question de problèmes qui corrélent aux moments où j'ai des problèmes de PLE / tampon. En outre, s'il s'agissait d'une mauvaise requête en cours d'exécution, je pense que les tampons seraient pleins de données de cette requête, pas vide / manquants / erreurs.
Ensuite, je pensais que la machine virtuelle obtenait sa mémoire restreinte lorsque cela s'est passé. Mais j'ai demandé à mon administrateur système et il m'assure que la mémoire n'est ni dynamique ni partagée. (Ce qu'il est assigné, il obtient tout le temps.) De plus, j'exécute ce script toutes les 10 minutes et lorsque le PLE signale moins de 50:
SELECT * FROM sys.dm_os_sys_memory
et cela indique les mêmes valeurs / valeurs similaires lorsque les PLE / tampons sont élevés et quand ils sont bas. En complétude, voici un exemple des valeurs avant et après # 24 ci-dessus:
total_physical_memory_kb available_physical_memory_kb total_page_file_kb available_page_file_kb system_cache_kb kernel_paged_pool_kb kernel_nonpaged_pool_kb system_high_memory_signal_state system_low_memory_signal_state system_memory_state_desc 20970996 4758672 24378868 7929404 4844160 686076 182752 1 0 Available physical memory is high 20970996 4743468 24378868 7892632 4845000 686580 182688 1 0 Available physical memory is high
J'ai vérifié la session de santé du système et cela ne montre rien de liaison. (Tout ce qu'il a fait des effets sur l'impersonnation, et leur temps ne correspond pas à l'époque que les PLE / tampons montrent des problèmes.
J'ai suivi à quelle fréquence cela se produit, je ne peux pas voir un modèle ou le connecter à des emplois ni à des activités planifiées.
Voici un graphique qui montre Ple et tampons de plus de 21 heures:
Donc je suis excentré. Je pense que le noyau de la question est que les tampons ne sont pas le PLE. (Je pense que Ple reçoit un faux rapport de faible car tous les tampons sont partis d'une manière ou d'une autre.)
Mais je ne peux penser à aucune façon que cela puisse arriver. Ou quoi faire ensuite.
J'aimerais donner des conseils sur des choses supplémentaires à vérifier ou à suggérer de ce que cette question pourrait être.
alors, combien de mémoire est donnée le serveur? le VM a 20 Go de mémoire.
quelle est la mémoire Max Server?
name value value_in_use description max server memory (MB) 13000 13000 Maximum size of server memory (MB) min server memory (MB) 0 16 Minimum size of server memory (MB)
Remarque: j'ai un peu de lecture à ce moment-là, et il semble que ces paramètres ne soient faux pour mon serveur.
Quelle est la taille de la base de données? Il existe deux bases de données transactionnelles exécutées sur ce serveur (je suis en train de recevoir des serveurs pour les isoler.) Leurs tailles sont de 383 Go et 378 gb.
quelles autres applications et services fonctionnent sur ce serveur? Ce serveur héberge les données de mon application. Il n'y a pas d'autre chose qui le frappe. (J'ai un magasin de données opérationnel répliqué pour des rapports et tels.
quelle est la technologie VM vm ware.
Est-ce que cette machine virtuelle est exécutée sur un hôte qui héberge uniquement VMS avec une allocation de ressources similaire? Nous avons de nombreux VMS chez notre société. Toute la taille variable. C'est l'un des plus grand cependant.
Pouvez-vous confirmer ce que votre administrateur système vous indique une allocation de mémoire sans simplement avoir à le croire? Je ne peux pas. Je n'ai pas accès à ces outils.
(dans mon expérience, System Admin dira beaucoup de choses pour réussir le Buck et blâmer l'application ou quelqu'un d'autre si cela signifie qu'ils ne doivent rien faire.) je peux pleinement comprendre ce sentiment.
ce modèle semble certainement être une pression de mémoire grave je suis d'accord. J'espérais trouver quelque chose pour prouver que SQL ressent une pression de mémoire. Donc, je peux le renvoyer aux admins du système pour plus de recherches.
statistiques de temps d'attente
WaitType Wait_S Resource_S Signal_S WaitCount Percentage AvgWait_S AvgRes_S AvgSig_S ---------------------- ----------- ----------- --------- ---------- ------------ ---------- --------- --------- PAGEIOLATCH_SH 16250.10 16219.14 30.96 2171649 29.59 0.0075 0.0075 0.0000 CXPACKET 14214.03 13238.56 975.47 1187935 25.88 0.0120 0.0111 0.0008 PAGEIOLATCH_EX 6814.59 6806.21 8.38 638725 12.41 0.0107 0.0107 0.0000 WRITELOG 5157.42 4873.44 283.98 3588476 9.39 0.0014 0.0014 0.0001 BACKUPIO 2569.51 2538.12 31.39 1704119 4.68 0.0015 0.0015 0.0000 LCK_M_IX 2477.15 2477.10 0.05 113 4.51 21.9217 21.9213 0.0004 ASYNC_IO_COMPLETION 2079.99 2079.66 0.33 836 3.79 2.4880 2.4876 0.0004 BACKUPBUFFER 1807.75 1759.11 48.64 380189 3.29 0.0048 0.0046 0.0001 IO_COMPLETION 986.23 985.84 0.39 116112 1.80 0.0085 0.0085 0.0000
La solution
Comme indiqué sur Ce thread de ce SE et confirmé par op.
Le problème est dû au bogue dans SQL Server 2012. ths bug a été corrigé dans SQL Server 2012 SP1 CU4 .Ou d'être sur Safer a déclaré que je vous recommanderais d'appliquer SQL Server 2012SP2 au lieu d'aller pour CU4.
selon Microsoft Bug Fix Détail
Vous pouvez rencontrer des performances lentes dans SQL Server 2012. Lorsque vous vérifiez Outils de surveillance des performances SQL Server, vous voyez les éléments suivants:
• Une baisse rapide du SQLSERVER: Gestionnaire tampon \ Evénération de la vie de la page valeurs de compteur de performance.Lorsque ce problème se produit, le compteur est près de 0.
Autres conseils
Votre piscine tampon est
La situation ci-dessus, si je dois imaginer, c'est comme ci-dessous:
Vous devez comprendre comment SQL Server stocke des informations:
SQL Server stocke des informations dans la mémoire dans une structure appelée cache de mémoire. Les informations contenues dans le cache peuvent être des données de données, des entrées d'index, des plans de procédure compilées et une variété d'autres types d'informations SQL Server. Pour éviter de réintroduire les informations, il est conservé le cache de mémoire aussi longtemps. Le plus possible et est
habituellement retiré du cache lorsqu'il est trop vieux pour être utile ou lorsque l'espace mémoire est nécessaire pour de nouvelles informations. Le processus qui supprime les anciennes informations est appelé balayage de la mémoire. Le balayage de la mémoire est une activité fréquente, mais n'est pas continue.
Vous êtes sûr sûr de faire l'expérience de la mémoire de mémoire en raison de la quantité de la taille de la base de données et de votre piscine tampon inadéquate. Reportez-vous à - Comment déterminer la mémoire idéale par exemple?
collecter Attendre Statistiques et Vérifier la performance Les problèmes découlant de la mémoire de la piscine tampon gaspillée
Ajoutez plus de mémoire à l'instance de serveur et séparez les deux bases de données sur différents VMS avec une mémoire adéquate.
Il y a très peu de déboguer ici - Vous devez ajouter de la mémoire, diviser logiquement votre base de données sur plusieurs ordinateurs virtuels ou comprendre que le mélange que vous avez à voir avec une mémoire limitée entraînera des problèmes de performance et de la volatille.En essayant d'installer 800 Go de données dans 13 Go de mémoire, c'est comme essayer de ranger dans un sac à dos.
Regarde plus près les requêtes étant exécutées.L'utilisation de la mémoire seule sur les bases de données est normalement trop grossière une métrique pour améliorer les choses.En supposant que vous ne puissiez pas affecter les requêtes (application Box Black), il vaut toujours la peine de comprendre ce qui affecte l'utilisation de la mémoire.Par exemple, un processus de lot peut aller utiliser tout l'espace tampon en un seul coup en interrogeant toutes les données sur une table massive.
En particulier, recherchez tous les index manquants qui entraînent des analyses de table complètes - car elles peuvent effacer efficacement le cache sur le serveur.
SQL Server dispose d'un excellent ensemble d'outils d'analyseur pouvant surveiller en temps réel, et je soupçonne que vous verrez quelque chose de bâtir comme un pouce endolori une fois que vous l'éloignez.
Non pas que je suggère de changer le schéma de base de données, mais une chose à rechercher est trop grande de champs de varchar, ils peuvent vraiment aspirer un espace de cache sur une grande base de données.