TokenAndPermUserStore Clear verringert die CPU-Auslastung für kurze Zeit

8

Intro

Kurz gesagt, auf meinem Server treten viele Ad-hoc-Abfragen von einer Anwendung auf, die ich nicht kontrolliere und nicht ändern kann (selbst das Verschieben von Indizes ist schwierig und sie verwenden viele Heaps ...).

Technische Daten

Betriebssystem - Windows Server 2012 R2 (Primärknoten) SQL Server 2014 - 12.0.5546

Always On AG Mit dem sekundären synchronen Knoten mit derselben Hardware + Build.

Erinnerung:

Aufgrund der Lizenzierung können wir nur 12 der 24 Kerne für SQL Server verwenden (ich habe dies nicht getan). Es ist ziemlich leicht zu erkennen, welche 12 Kerne;). CPU auslastung

Das Problem

Nun zu meinem Problem. Momentan löschen wir alle 30 Minuten den "TokenAndPermUserStore". Dies geschah auf dem Server, noch bevor es in meine Hände kam. Wir haben dies mit dem Befehl gemacht:

DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')

Ich benutze diese Abfrage, um den Cache zu überprüfen:

SELECT SUM(pages_kb) / 1024  AS 
   "CurrentSizeOfTokenCache(mb)" 
   FROM sys.dm_os_memory_clerks 
   WHERE name = 'TokenAndPermUserStore'

Gleich nach dem Löschen ist dies die Cache-Größe:

CurrentSizeOfTokenCache(mb)
1602

Zu einem bestimmten Zeitpunkt, z. B. 15 Minuten nach dem Löschen, ist dies die Cache-Größe:

CurrentSizeOfTokenCache(mb)
1976

Update: Wenn die verwendete CPU wieder stabil ist (40% verwendet (20% bei der Überwachung)), liegt der Cache weit unter dem niedrigsten Punkt, an dem die CPU-Auslastung hoch war.

CurrentSizeOfTokenCache(mb)
1281

Ein Beispiel von gestern:

Die Tropfen sind auf diesem Bild von gestern sehr präsent: (Beachten Sie, dass wir 12 der 24 Kerne verwenden können, 50% bedeutet 100% in der Überwachungssoftware, mit anderen Worten, die CPU-Auslastung wird wahrscheinlich 50% nicht überschreiten, da sie dafür vorgesehen ist nur SQL Server)

Geben Sie hier die Bildbeschreibung ein

Eine wichtige Sache ist, dass wir gestern zwei wichtige Indizes zu den Top-Abfragen hinzugefügt haben, da die CPU fast flach ist, was für kurze Zeit hilfreich war, aber die CPU wieder auf das gleiche Niveau gestiegen ist, ohne erkennbare Abfragen, die hämmern sollten unser System so schwer.

Die Frage

Auf meine Frage habe ich heute versucht, den Cache häufiger durch Ausführen zu leeren 

DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')

einige Male manuell. Aber es schien, dass nach ungefähr 20 Sekunden die CPU-Nutzung mit aller Macht zurückkam.

Sie können die drei Einbrüche nach dem Ausführen des Befehls deutlich sehen, aber im Bild unten kommt es ziemlich schnell zurück.

Geben Sie hier die Bildbeschreibung ein

Sollte ich den Befehl mehr planen, sollte ich mir andere Änderungen ansehen?

Ich weiß, dass dieses Problem in SQL Server 2005 weit verbreitet war, dies ist jedoch SQL Server 2014. Bei den Abfragen handelt es sich um Abfragen vom Typ sp_executesql.

Wenn Sie weitere Informationen oder Erläuterungen benötigen, zögern Sie nicht, mich zu informieren.

Update vom 05/12/2018

Abfrageplan: https://www.brentozar.com/pastetheplan/?id=BkUKKVByV

-> Einfügen Der Plan erstellt den gleichen Link für die drei gefundenen Pläne. Ich habe versucht, alle drei im Cache gefundenen XML-Pläne für dieselbe Abfrage mit jeweils 10 Ausführungen hinzuzufügen, und für jede Abfrage denselben Link erhalten.

Abfrage verwendet

    SELECT 
  text, execution_count,
dm_exec_query_stats.creation_time, dm_exec_query_plan.query_plan
FROM sys.dm_exec_query_stats 
CROSS APPLY sys.dm_exec_sql_text(dm_exec_query_stats.plan_handle)
CROSS APPLY sys.dm_exec_query_plan(plan_handle)

Ergebnisse für drei gleiche Abfragen:

Geben Sie hier die Bildbeschreibung ein

Ich möchte darauf hinweisen, dass die Abfragen SNAPSHOT ISOLATION verwenden, indem sie vor dem Ausführen der Abfrage festgelegt werden und die Hinweise OPTION (KEEP PLAN, KEEPFIXED PLAN, LOOP JOIN) verwenden.

Abfrage 1

(@SV1 nvarchar(8),@SV2 nvarchar(8),@SV3 nvarchar(8),@SV4 nvarchar(8),@SV5 nvarchar(8),@SV6 nvarchar(8),@SV7 nvarchar(8),@SV8 nvarchar(8),@SV9 nvarchar(8),@SV10 nvarchar(8),@SV11 nvarchar(8),@SV12 nvarchar(8),@SV13 nvarchar(8),@SV14 nvarchar(8),@SV15 nvarchar(8),@SV16 nvarchar(8),@SV17 nvarchar(8),@SV18 nvarchar(8),@SV19 nvarchar(8))  IF @@TRANCOUNT = 0 SET TRANSACTION ISOLATION LEVEL SNAPSHOT  SELECT AA.[SourceCode],AA.[DOUBLEMEDICATIONSVALIDATED],AA.[BSTNUM],AA.[MUTKOD],AA.[VERVALLEN],AA.[BACKUPID],AA.[LAATSTE],AA.[ExterneCode],AA.[PRKODE],AA.[NMMEMO],AA.[NMETIK],AA.[NMNM40],AA.[NMNAAM],AA.[PRNMNR],AA.[PRKBST],AA.[GPKODE],AA.[DRMLGEN],AA.[Anticoagulant],AA.[HPKSubstancesDiff],AA.[HPKCIsDiff],AA.[HPKUndesiredGroupsDiff]  FROM [dbo].[ZINDEX_050] AA  WHERE EXISTS (SELECT NULL  FROM (SELECT TOP 100 PERCENT  A.[BSTNUM],A.[MUTKOD],A.[VERVALLEN],A.[BACKUPID],A.[DMPRKA],A.[DMPRKB],A.[DMCODE],A.[DMGRDCODE]  FROM [dbo].[ZINDEX_671] A  WHERE ((A.[VERVALLEN] = 0 OR A.[VERVALLEN] IS NULL) AND ((A.[DMPRKA] = @SV1 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV4) OR  (A.[DMPRKA] = @SV5 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV6 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV7) OR  (A.[DMPRKA] = @SV8 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV9 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV10) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV11) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV12) OR  (A.[DMPRKA] = @SV13 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV14) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV15) OR  (A.[DMPRKA] = @SV16 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV17 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV18 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV19)))  ) A  WHERE AA.[PRKODE] = A.[DMPRKA])  OPTION (KEEP PLAN, KEEPFIXED PLAN, LOOP JOIN)    SELECT AB.[SourceCode],AB.[DOUBLEMEDICATIONSVALIDATED],AB.[BSTNUM],AB.[MUTKOD],AB.[VERVALLEN],AB.[BACKUPID],AB.[LAATSTE],AB.[ExterneCode],AB.[PRKODE],AB.[NMMEMO],AB.[NMETIK],AB.[NMNM40],AB.[NMNAAM],AB.[PRNMNR],AB.[PRKBST],AB.[GPKODE],AB.[DRMLGEN],AB.[Anticoagulant],AB.[HPKSubstancesDiff],AB.[HPKCIsDiff],AB.[HPKUndesiredGroupsDiff]  FROM [dbo].[ZINDEX_050] AB  WHERE EXISTS (SELECT NULL  FROM (SELECT TOP 100 PERCENT  A.[BSTNUM],A.[MUTKOD],A.[VERVALLEN],A.[BACKUPID],A.[DMPRKA],A.[DMPRKB],A.[DMCODE],A.[DMGRDCODE]  FROM [dbo].[ZINDEX_671] A  WHERE ((A.[VERVALLEN] = 0 OR A.[VERVALLEN] IS NULL) AND ((A.[DMPRKA] = @SV1 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV4) OR  (A.[DMPRKA] = @SV5 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV6 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV7) OR  (A.[DMPRKA] = @SV8 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV9 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV10) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV11) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV12) OR  (A.[DMPRKA] = @SV13 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV14) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV15) OR  (A.[DMPRKA] = @SV16 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV17 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV18 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV19)))  ) A  WHERE AB.[PRKODE] = A.[DMPRKB])  OPTION (KEEP PLAN, KEEPFIXED PLAN, LOOP JOIN)    SELECT A.[BSTNUM],A.[MUTKOD],A.[VERVALLEN],A.[BACKUPID],A.[DMPRKA],A.[DMPRKB],A.[DMCODE],A.[DMGRDCODE]  FROM [dbo].[ZINDEX_671] A  WHERE ((A.[VERVALLEN] = 0 OR A.[VERVALLEN] IS NULL) AND ((A.[DMPRKA] = @SV1 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV4) OR  (A.[DMPRKA] = @SV5 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV6 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV7) OR  (A.[DMPRKA] = @SV8 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV9 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV10) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV11) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV12) OR  (A.[DMPRKA] = @SV13 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV14) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV15) OR  (A.[DMPRKA] = @SV16 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV17 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV18 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV19)))  ORDER BY A.[DMPRKA] ASC,A.[DMPRKB] ASC  OPTION (KEEP PLAN, KEEPFIXED PLAN, LOOP JOIN)

Abfrage 2

(@SV1 nvarchar(8),@SV2 nvarchar(8),@SV3 nvarchar(8),@SV4 nvarchar(8),@SV5 nvarchar(8),@SV6 nvarchar(8),@SV7 nvarchar(8),@SV8 nvarchar(8),@SV9 nvarchar(8),@SV10 nvarchar(8),@SV11 nvarchar(8),@SV12 nvarchar(8),@SV13 nvarchar(8),@SV14 nvarchar(8),@SV15 nvarchar(8),@SV16 nvarchar(8),@SV17 nvarchar(8),@SV18 nvarchar(8),@SV19 nvarchar(8))  IF @@TRANCOUNT = 0 SET TRANSACTION ISOLATION LEVEL SNAPSHOT  SELECT AA.[SourceCode],AA.[DOUBLEMEDICATIONSVALIDATED],AA.[BSTNUM],AA.[MUTKOD],AA.[VERVALLEN],AA.[BACKUPID],AA.[LAATSTE],AA.[ExterneCode],AA.[PRKODE],AA.[NMMEMO],AA.[NMETIK],AA.[NMNM40],AA.[NMNAAM],AA.[PRNMNR],AA.[PRKBST],AA.[GPKODE],AA.[DRMLGEN],AA.[Anticoagulant],AA.[HPKSubstancesDiff],AA.[HPKCIsDiff],AA.[HPKUndesiredGroupsDiff]  FROM [dbo].[ZINDEX_050] AA  WHERE EXISTS (SELECT NULL  FROM (SELECT TOP 100 PERCENT  A.[BSTNUM],A.[MUTKOD],A.[VERVALLEN],A.[BACKUPID],A.[DMPRKA],A.[DMPRKB],A.[DMCODE],A.[DMGRDCODE]  FROM [dbo].[ZINDEX_671] A  WHERE ((A.[VERVALLEN] = 0 OR A.[VERVALLEN] IS NULL) AND ((A.[DMPRKA] = @SV1 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV4) OR  (A.[DMPRKA] = @SV5 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV6 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV7) OR  (A.[DMPRKA] = @SV8 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV9 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV10) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV11) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV12) OR  (A.[DMPRKA] = @SV13 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV14) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV15) OR  (A.[DMPRKA] = @SV16 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV17 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV18 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV19)))  ) A  WHERE AA.[PRKODE] = A.[DMPRKA])  OPTION (KEEP PLAN, KEEPFIXED PLAN, LOOP JOIN)    SELECT AB.[SourceCode],AB.[DOUBLEMEDICATIONSVALIDATED],AB.[BSTNUM],AB.[MUTKOD],AB.[VERVALLEN],AB.[BACKUPID],AB.[LAATSTE],AB.[ExterneCode],AB.[PRKODE],AB.[NMMEMO],AB.[NMETIK],AB.[NMNM40],AB.[NMNAAM],AB.[PRNMNR],AB.[PRKBST],AB.[GPKODE],AB.[DRMLGEN],AB.[Anticoagulant],AB.[HPKSubstancesDiff],AB.[HPKCIsDiff],AB.[HPKUndesiredGroupsDiff]  FROM [dbo].[ZINDEX_050] AB  WHERE EXISTS (SELECT NULL  FROM (SELECT TOP 100 PERCENT  A.[BSTNUM],A.[MUTKOD],A.[VERVALLEN],A.[BACKUPID],A.[DMPRKA],A.[DMPRKB],A.[DMCODE],A.[DMGRDCODE]  FROM [dbo].[ZINDEX_671] A  WHERE ((A.[VERVALLEN] = 0 OR A.[VERVALLEN] IS NULL) AND ((A.[DMPRKA] = @SV1 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV4) OR  (A.[DMPRKA] = @SV5 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV6 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV7) OR  (A.[DMPRKA] = @SV8 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV9 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV10) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV11) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV12) OR  (A.[DMPRKA] = @SV13 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV14) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV15) OR  (A.[DMPRKA] = @SV16 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV17 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV18 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV19)))  ) A  WHERE AB.[PRKODE] = A.[DMPRKB])  OPTION (KEEP PLAN, KEEPFIXED PLAN, LOOP JOIN)    SELECT A.[BSTNUM],A.[MUTKOD],A.[VERVALLEN],A.[BACKUPID],A.[DMPRKA],A.[DMPRKB],A.[DMCODE],A.[DMGRDCODE]  FROM [dbo].[ZINDEX_671] A  WHERE ((A.[VERVALLEN] = 0 OR A.[VERVALLEN] IS NULL) AND ((A.[DMPRKA] = @SV1 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV4) OR  (A.[DMPRKA] = @SV5 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV6 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV7) OR  (A.[DMPRKA] = @SV8 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV9 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV10) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV11) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV12) OR  (A.[DMPRKA] = @SV13 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV14) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV15) OR  (A.[DMPRKA] = @SV16 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV17 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV18 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV19)))  ORDER BY A.[DMPRKA] ASC,A.[DMPRKB] ASC  OPTION (KEEP PLAN, KEEPFIXED PLAN, LOOP JOIN)

Es tut weh, es anzuschauen, ich weiß.

Kompiliert auch bei erzwungener Parametrierung

Die Kompilierung / Sek. Stimmt mit Batches / Sek. Fast 1 zu 1 überein, selbst wenn die erzwungene Parametrierung aktiviert ist. Aus diesem Grund ist die Zeile Batches / Sek. Ausgeblendet (sie befindet sich hinter der Zeile Kompilierungen / Sek.).

Geben Sie hier die Bildbeschreibung ein

Perfmon-Statistiken:

Geben Sie hier die Bildbeschreibung ein

Abfragen, CPU, E / A, wenn die CPU etwa 80% und die CPU etwa 40% beträgt

Die Aggregate von Abfragen, die heute im Zeitrahmen von 13:00 bis 13:00 Uhr (80% CPU-Auslastung) ausgeführt wurden: Geben Sie hier die Bildbeschreibung ein

CPU auslastung: Geben Sie hier die Bildbeschreibung ein

Es gibt einen Unterschied zu dem Zeitpunkt, an dem die CPU-Auslastung heute zwischen 2u05 PM und 2u25PM niedriger ist (40% CPU-Auslastung). Geben Sie hier die Bildbeschreibung ein

CPU auslastung:

Geben Sie hier die Bildbeschreibung ein

Der erste ist der, bei dem wir einen Index hinzugefügt haben, als wir Probleme sahen, und die CPU-Auslastung verringert haben.

Zusätzliche Fragen mit Schecks und mehr Infos:

   select count(*) as amount_of_USERSTORE_TOKENPERM from sys.dm_os_memory_clerks
   where type = 'USERSTORE_TOKENPERM'

amount_of_USERSTORE_TOKENPERM
15190



     select count(*)  as amount_of_connections from sys.dm_exec_connections 
amount_of_connections
10004


       select  value_in_use from sys.configurations
       where name like '%access check cache bucket count%'

value_in_use
0
          select value_in_use from sys.configurations
       where name like '%access check cache quota%'
value_in_use
0
sql-server sql-server-2014 Randi Vertongen
quelle
4
Haben Sie versucht, die erzwungene Parametrisierung für die beteiligten Datenbanken zu aktivieren? Es gibt Nachteile - zum Beispiel ist es schwieriger, gefilterte Indizes zu verwenden -, aber wenn es gut passt, erhalten Sie sofort eine Wiederverwendung des Plans, was weniger Kompilierungen pro Sekunde bedeutet und die CPU sinkt. (Es scheint auch den TokenAndPermUserStore-Cache zu reduzieren.)
Brent Ozar
2
Haben Sie festgestellt, was genau die hohe CPU-Auslastung verursacht? Sie haben nur "keine erkennbaren Fragen" gesagt, aber was ist es dann? Ich frage mich, wie viel vom TokenAndPermUserStore Korrelation gegen Kausalität ist.
Aaron Bertrand
4
@sp_BlitzErik Sie können nicht weniger als die Anzahl der Kerne auf einem Server (oder vCores auf einer VM) lizenzieren. Siehe download.microsoft.com/download/7/8/C/…
David Browne - Microsoft
2
Dieser Server verfügt über 12 Kerne, die auf 24 hyperthreaded sind. Daher sind 12 Kernlizenzen erforderlich. Es gibt keinen Lizenzierungsgrund, um die CPU-Affinität festzulegen. Wenn Sie die CPU-Affinität festlegen, sollte SQL auf 0,2,4, ... ausgeführt werden, um zu vermeiden, dass zwei Aufgaben auf einem physischen Kern geplant werden.
David Browne - Microsoft
2
Wenn Sie einen Socket im BIOS deaktivieren, wird er in Windows nicht angezeigt und Sie können nicht auf die Hälfte des Speichers zugreifen.
David Browne - Microsoft

Antworten:

2

Vielen Dank für Ihre Zeit und Mühe bei der Suche nach einer Lösung. Besonders @David Browne - Microsoft, da er Recht hatte, indem er mich wissen ließ, dass wir patchen sollten.

Wir hatten ein Treffen mit den Datenbank, den Anwendungsinhabern und dem technischen Team des Anwendungsanbieters.

In dieser Besprechung stellte sich heraus, dass bei den anderen Kunden, die der Anbieter hat, aufgrund der Art der Anwendung und ihres Codes dasselbe Problem vorliegt.

Ähnlich wie dies.

Die Lösung, die ihren anderen Kunden bei diesem Problem geholfen hat, besteht darin, auf SQL Server 2014 CU7 oder SP3 zu aktualisieren, was wir so bald wie möglich tun werden (vorzugsweise SP3), um die Probleme mit dem Token- und Permuserstore zu beenden.

Randi Vertongen
quelle
Meinten Sie SQL Server 2014 SP2 CU7? Wir sehen ein seltsames Verhalten mit dem USERSTORE_TOKENPERM-Cache (168.000 Datensätze, häufiges Löschen des Plan-Cache) und ich hoffe, dass dies eine Lösung sein könnte.
Jacob H
Es tut mir leid, dass ich weiter kommentiere, aber ich denke, Sie sind die einzige andere Person auf dem Planeten, die dieses Problem sieht. Es scheint von einer unserer Apps von Drittanbietern zu stammen, die einen "interessanten" Ansatz zur Authentifizierung mit Identitätswechsel verwendet und außerdem eine Menge Verbindungen für jeden Benutzer herstellt. Wie Sie bereits sagten, stabilisiert das regelmäßige Löschen des Token-Cache den Plan-Cache vorübergehend. Wir sind auf SP2 2014 und der Anbieter hat SP3 noch nicht speziell genehmigt. Ich hoffe, dass 2014 SP2 CU7 das Update hat.
Jacob H
@JacobH Kein Problem, unser Problem war eine Kombination aus zwei. Das erste, das die Instanz patcht, das zweite war ein BIOS-Update, das auf dem Computer durchgeführt wurde, der entfernt werden musste. Beide Dinge wurden mir von anderen erzählt und ich habe diese Änderungen leider nicht selbst vorgenommen, da ich zu diesem Zeitpunkt ein kurzfristiges Projekt mit dem Kunden hatte.
Randi Vertongen
0

Haben Sie irgendetwas ausgeführt, um festzustellen, welche Abfragen die meiste CPU-Zeit (auch als Arbeitszeit bezeichnet) beitragen? Vielleicht so etwas wie unten (Zeit ist in Mikrosekunden)? In Ihrem ersten Beitrag habe ich gesehen, dass Sie mehrere Fragen identifiziert haben - wie haben Sie festgestellt, dass diese möglicherweise problematisch sind? 

select top 100 SUBSTRING(b.text,statement_start_offset / 2+1 ,   
  ( (CASE WHEN statement_end_offset = -1   
     THEN (LEN(CONVERT(nvarchar(max),b.text)) * 2)   
     ELSE statement_end_offset END)  - statement_start_offset) / 2+1), 
     convert(xml, c.query_plan), a.execution_count, 
a.total_worker_time, a.total_elapsed_time 
from sys.dm_exec_query_stats a 
cross apply sys.dm_exec_sql_text(a.sql_handle) b 
cross apply sys.dm_exec_text_query_plan(a.plan_handle, 
a.statement_start_offset, a.statement_end_offset) c
order by a.total_worker_time desc

Sehen Sie, dass Sie viele Einwegpläne (über dmvs) haben, oder gehen Sie davon aus, dass dies aufgrund der Kompilierungsraten der Fall ist, die Sie in der Tabelle angezeigt haben? Die folgende Abfrage berücksichtigt keine Einwegpläne. Wenn dies jedoch nicht funktioniert, kann ich Ihnen eine senden, die dies tut.

Sqlgrease
quelle
Einwegpläne sind hoch und werden nicht angenommen. Bei einer Abfrage überprüft, waren es etwa 50% aller Pläne. Trotzdem erklärt es nicht, warum ich drei Pläne für genau dieselbe Abfrage habe, das XML stimmt vollständig überein, aber die Pläne wurden nicht wiederverwendet. Ich denke, dass das Lesen aus dem Cache ab sofort keine Hilfe sein wird, da das CPU-Flatlining nur zu bestimmten Zeitpunkten stattfindet. Ab sofort sind es ein paar Wochen.
Randi Vertongen
Haben Sie sich sys.dm_exec_plan_attributes angesehen? Das könnte Ihnen zeigen, warum Sie 3 Pläne für dieselbe Abfrage haben. Wenn Sie sich die Spalte is_cache_key ansehen, in der Sie erfahren, ob das Attribut berücksichtigt wird, wenn ermittelt wird, ob ein zwischengespeicherter Plan genutzt werden kann oder ob ein neuer erstellt werden muss.
Sqlgrease