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 8.012 à 313 .

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:

 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.

mises à jour des questions dans les commentaires:

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   

Était-ce utile?

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 seulement 13 Go et vos bases de données sont de 383 gb et 378 Go que vous avez classé comme OLTP - petites transactions fonctionnant trop fréquemment.

La situation ci-dessus, si je dois imaginer, c'est comme ci-dessous:

 Entrez la description de l'image ici (source: Google Photos)

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

Recommandation:

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.

Licencié sous: CC-BY-SA avec attribution
Non affilié à dba.stackexchange
scroll top