Helfen Sie dabei, die Diskrepanz zwischen sys.dm_exec_cached_plans und dm_os_memory_clerks zu verstehen


7

Bei einer unserer SQL Server 2014-Instanzen besteht eine merkwürdige Diskrepanz zwischen der Speichermenge, die für zwischengespeicherte Pläne gemäß sys.dm_exec_cached_plans verwendet wird, und der Speichermenge, die gemäß sys.dm_os_memory_clerks für den Typ CACHESTORE_SQLCP verwendet wird (was ich verstehe) ist für zwischengespeicherte Ad-hoc-Abfragepläne).

Wenn wir die zwischengespeicherten Pläne wie folgt abfragen:

select cp.cacheobjtype, cp.objtype, 
  sum(cast(cp.size_in_bytes as money))/1024/1024 as sizeMB
from sys.dm_exec_cached_plans as cp
group by cp.cacheobjtype, cp.objtype;

Dann scheinen insgesamt etwa 90 MB für zwischengespeicherte Pläne verwendet zu werden, wobei nur 2 MB für Ad-hoc-Pläne verwendet werden. Es gibt auch nur 300 Pläne im Cache.

Wenn wir uns jedoch die Ansicht dm_os_memory_clerks wie folgt ansehen:

select mc.type, mc.pages_kb/1024 as pagesMB
from sys.dm_os_memory_clerks as mc
where mc.type = 'CACHESTORE_SQLCP'

dann wird berichtet, dass ungefähr 12 GB verwendet werden. Unsere Instanz hat ca. 300 GB RAM drin.

Wir möchten die Diskrepanz verstehen und im Idealfall einige Schritte unternehmen, um sicherzustellen, dass der Plan-Cache effektiv genutzt wird (dh mehr als 300 Pläne zur Verbesserung der Cache-Trefferquote, die derzeit sehr schlecht ist). Diesen Raum berücksichtigen zu können, wäre der erste Schritt.

Irgendwelche Gedanken darüber, was die Diskrepanz sein könnte und warum dieser Bereich nicht zum Zwischenspeichern von Plänen verwendet wird?


2
Das hat nichts mit dem Problem zu tun, aber warum money?
Aaron Bertrand

Um ehrlich zu sein, nur weil ich diesen Code von irgendwo online kopiert und eingefügt hatte, als ich mir Beispielabfragen für zwischengespeicherte Pläne angesehen hatte, und mich nicht darum gekümmert hatte, den dort verwendeten Datentyp zu ändern
Paul McLoughlin

1
Ist das eine NUMA-Maschine? Wie viele NUMA-Knoten und wie viele Kerne pro Knoten?
Aaron Bertrand

@ PaulMcLoughlin: Aaron fragte nach NUMA Maschine hast du es? Dieses Verhalten kann aufgrund von NUMA auftreten. Können Sie bitte bestätigen
Shanky

Soweit ich das beurteilen kann, haben wir 2 NUMA-Knoten, beide mit online_scheduler_count von 16, ohne dass ein virtueller Adressraum für den zweiten Knoten reserviert ist. Dies ergibt sich aus der folgenden Abfrage: Wählen Sie n.node_id, n.node_state_desc, n.online_scheduler_count, n.processor_group, n.memory_node_id, CAST ((m.virtual_address_space_reserved_kb / 1024.0 / 1024) AS INT) als reservedMemoryN JOIN sys.dm_os_memory_nodes m ON n.memory_node_id = m.memory_node_id WHERE n.node_state_desc NICHT WIE '% DAC%' ORDER BY n.node_id
Paul McLoughlin

Antworten:


1

FWIW - und ich poste dies nur als vorübergehende Antwort, da ich dies auf keinen Fall zu einem verdaulichen Kommentar machen kann - Ich habe diese Abfragen ausgeführt und auch einige Unstimmigkeiten festgestellt:

select cp.cacheobjtype, cp.objtype, 
  sum(cast(cp.size_in_bytes as DECIMAL(19,4)))/1024/1024 as sizeMB
from sys.dm_exec_cached_plans as cp
group by cp.cacheobjtype, cp.objtype
ORDER BY sizeMB DESC;

select mc.type, mc.pages_kb/1024 as pagesMB
from sys.dm_os_memory_clerks as mc
where mc.type LIKE N'CACHESTORE[_]%'
ORDER BY pagesMB DESC;

Insbesondere ist die CACHESTORE_SQLCP-Summe in der zweiten Abfrage geringer als die vier Ergebnisse des kompilierten Plans in der ersten Abfrage, und auch unter anderen Cachestores wurde ein erheblicher Speicherangestellter verwendet. Dies ist eine niedrige VM, die nicht über 300 GB RAM verfügt, aber dennoch zeigt, dass diese Zahlen nicht immer korrelieren und sich gut summieren.

Geben Sie hier die Bildbeschreibung ein


1
Aaron, könnte es ein kompilierter Plan gegen einen Ausführungsplan sein? "Ausführbare Pläne oder Ausführungskontexte gelten als abhängig von kompilierten Plänen und werden nicht in der Ansicht sys.dm_exec_cached_plans angezeigt. Ausführbare Pläne sind Laufzeitobjekte, die bei der Ausführung eines kompilierten Plans erstellt werden. Genau wie bei kompilierten Plänen können ausführbare Pläne Objektpläne, die im Objektspeicher gespeichert sind, oder SQL-Pläne, die im SQL-Speicher gespeichert sind. Jeder ausführbare Plan befindet sich im selben Cache-Speicher wie der kompilierte Plan, von dem er abhängig ist. " Plan Cache Internals
DenisT

Ich möchte dieses Problem lösen, da ich etwas Ähnliches erlebe: Angestellte zeigen> 5 GB an, während zwischengespeicherte Pläne 100 MB groß sind - die Diskrepanz des OP ist noch größer - DenisT: Ich denke, Sie haben verstanden, warum sie nicht genau in einer Reihe stehen, aber das stimmt nicht Erklären Sie nicht die großen Abweichungen in der Größenordnung, die wir sehen ...
Mike DeFehr

Wir sind nie auf den Grund gegangen, warum wir diese Diskrepanz gesehen haben, aber nach einem BCP-Test (bei dem wir den Server neu gestartet haben) verschwand die Diskrepanz - und die anderen Symptome, die wir wie eine schlechte Cache-Trefferquote hatten, verschwanden ebenfalls.
Paul McLoughlin

@ Paul ist es wie Windows! Kann ein Problem nicht lösen? Neustart, es wird sich von selbst lösen!
Aaron Bertrand
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.