Problèmes de mémoire: TEMPDB utilisant presque tout le cache tampon

Question

Sur l'un des serveurs, je travaille sur aujourd'hui, je vois que la quasi-totalité du cache tampon est remplie de TEMPDB. En conséquence, la mémoire est très faible sur le serveur.

CPU

TEMPDB:

Version:

Microsoft SQL Server 2014 (SP2-CU13) (KB4456287) - 12.0.5590.1 (x64)
1 août 2018 01:23:36 Copyright (c) Edition standard de Microsoft Corporation (64 bits) sur Windows NT 6.3 (Build 14393 :) (Hyperviseur)

4 fichiers de données = 4096 MB 1 fichier journal = 1536MB

Mon problème est que Tempdb utilise 13 Go de mon cache tampon. J'ai vérifié les objets dans TEMPDB, les plus gros où mes tables Temps sp_blitz, qui ne sont pas si grandes.

RCSI n'est activé pour aucune base de données, donc ne devrait pas être un problème de magasin de version.

Pas de transactions ouvertes

Pas de curseurs ouverts.

Lorsque j'exécute un point de contrôle sur TEMPDB, cela prend environ 30 secondes, mais se termine.

Lorsque j'exécute DBCC Dropcleanbuffers, la présence de Tempdb dans le cache tampon est réduite TTO parfois 1 Go parfois 4GB 30 secondes plus tard, il est de retour dans sa gloire complète de 13 Go

Par exemple:

dbcc dropcleanbuffers


DECLARE @total_buffer INT;

SELECT @total_buffer = cntr_value
FROM sys.dm_os_performance_counters 
WHERE RTRIM([object_name]) LIKE '%Buffer Manager'
AND counter_name = 'Database Pages';

;WITH src AS
(
SELECT 
database_id, db_buffer_pages = COUNT_BIG(*)
FROM sys.dm_os_buffer_descriptors
--WHERE database_id BETWEEN 5 AND 32766
GROUP BY database_id
)
SELECT
[db_name] = CASE [database_id] WHEN 32767 
THEN 'Resource DB' 
ELSE DB_NAME([database_id]) END,
db_buffer_pages,
db_buffer_MB = db_buffer_pages / 128,
db_buffer_percent = CONVERT(DECIMAL(6,3), 
db_buffer_pages * 100.0 / @total_buffer)
FROM src
ORDER BY db_buffer_MB DESC; 

Résulter juste après:

db_name db_buffer_pages db_buffer_MB    db_buffer_percent
tempdb  620627  4848    58.096

30 sec plus tard:

db_name db_buffer_pages db_buffer_MB    db_buffer_percent
tempdb  1313835 10264   83.560

Utilisation de cache tampon TempDB à son apogée (its_over_9000.jpeg)

Vérifiez les objets dans TEMPDB:

use tempdb 

go
SELECT 
    t.NAME AS TableName,
    s.Name AS SchemaName,
    p.rows AS RowCounts,
    SUM(a.total_pages) * 8 AS TotalSpaceKB, 
    SUM(a.used_pages) * 8 AS UsedSpaceKB, 
    (SUM(a.total_pages) - SUM(a.used_pages)) * 8 AS UnusedSpaceKB
FROM sys.tables t
INNER JOIN sys.indexes i ON t.OBJECT_ID = i.object_id
INNER JOIN sys.partitions p ON i.object_id = p.OBJECT_ID AND i.index_id = p.index_id
INNER JOIN sys.allocation_units a ON p.partition_id = a.container_id
LEFT OUTER JOIN sys.schemas s ON t.schema_id = s.schema_id
GROUP BY  t.Name, s.Name, p.Rows
ORDER BY  TotalSpaceKB desc

Top 4 valeurs:

TableName   SchemaName  RowCounts   TotalSpaceKB    UsedSpaceKB UnusedSpaceKB
#A3B2C869   dbo 0   72  16  56
#A52E4149   dbo 0   72  16  56
#A59B10DB   dbo 0   72  16  56
#A68F3514   dbo 0   72  16  56

pour un total d'un montant de 74 objets.

Je vois beaucoup de pages (375 000 + !!!) avec 7965 octets d'espace libre et une seule rangée compte dans ma mémoire tampon. Requête utilisée:

select * from sys.dm_os_buffer_descriptors
where database_id = 2
order by free_space_in_bytes desc 

E.g.

file_id page_id page_level  allocation_unit_id  page_type   row_count   free_space_in_bytes
1   109763  0   71635384526569472   INDEX_PAGE  1   7965

mais encore plus avec 40 octets de l'espace libre (1M), voir ci-dessous.

Filtrer un peu plus:

select page_type,free_space_in_bytes,  count(*)as counter from sys.dm_os_buffer_descriptors
where database_id = 2
group by page_type, free_space_in_bytes
having count(*) > 500
order by free_space_in_bytes desc 

Question

Pourquoi mon tempdb se remplit-t-il si vite après avoir délivré DBCC Dropcleanbuffers? Est-ce que je manque quelque chose, que dois-je vérifier?

Mise à jour 30/11/2018

Afer Réglage TEMPDB sous forme de 4 fichiers de 512 Mo et redémarrage du serveur, le MB dans la mémoire tampon semble être inférieur. Cependant, il reste 6 Go.

Toute autre idée sur quoi faire/vérifier maintenant?

Info supplémentaire:

Tracetatus

Exemples de requêtes exécutées constantes capturées par le profileur:

exec sp_reset_connection 

SELECT COUNT(*) FROM dbo.SomeTable WHERE Error IS NULL

Certaines connexions utilisent Serializable:

-- network protocol: TCP/IP
set quoted_identifier on
set arithabort off
set numeric_roundabort off
set ansi_warnings on
set ansi_padding on
set ansi_nulls on
set concat_null_yields_null on
set cursor_close_on_commit off
set implicit_transactions off
set language us_english
set dateformat mdy
set datefirst 7
set transaction isolation level serializable 

Certains ne

-- network protocol: TCP/IP
set quoted_identifier on
set arithabort off
set numeric_roundabort off
set ansi_warnings on
set ansi_padding on
set ansi_nulls on
set concat_null_yields_null on
set cursor_close_on_commit off
set implicit_transactions off
set language us_english
set dateformat mdy
set datefirst 7
set transaction isolation level read committed

Max Mem est un peu bas:

Vérifications de la page DBCC: DBCC Traceon (3604);

DBCC Page (2, 5, 474258, 3); DBCC Traceoff (3604);

bpage = 0x00000016AA16C000          bhash = 0x0000000000000000          bpageno = (5:474258)
bdbid = 2                           breferences = 0                     bcputicks = 0
bsampleCount = 0                    bUse1 = 1952                        bstat = 0x109
blog = 0xcdcdcdcd                   bnext = 0x0000000000000000          

PAGE HEADER:


Page @0x00000016AA16C000

m_pageId = (5:474258)               m_headerVersion = 1                 m_type = 3
m_typeFlagBits = 0x0                m_level = 0                         m_flagBits = 0x8020
m_objId (AllocUnitId.idObj) = -1778255884                                m_indexId (AllocUnitId.idInd) = 255
Metadata: AllocUnitId = 71941054260314112                                Metadata: PartitionId = 0
Metadata: IndexId = -1              Metadata: ObjectId = 0              m_prevPage = (0:0)
m_nextPage = (0:0)                  pminlen = 0                         m_slotCnt = 1
m_freeCnt = 40                      m_freeData = 8150                   m_reservedCnt = 0
m_lsn = (5148:180860:473)           m_xactReserved = 0                  m_xdesId = (0:0)
m_ghostRecCnt = 0                   m_tornBits = 0                      DB Frag ID = 1

Allocation Status

GAM (5:2) = NOT ALLOCATED           SGAM (5:3) = NOT ALLOCATED          PFS (5:469104) = 0x4 100_PCT_FULL
DIFF (5:6) = NOT CHANGED            ML (5:7) = NOT MIN_LOGGED           


Blob row at: Page (5:474258) Slot 0 Length: 8054 Type: 3 (DATA)

Blob Id:2794796220416



000000464FAFA06E:  0044002b  006f0051  00550038  00520058 +.D.Q.o.8.U.X.R.
...

@CRAIG Votre sortie:

Answer 1

Pas sûr, mais la jointure entre sys.allocation_units et sys.partitions n'est pas tout à fait juste par Docs . PAR EXEMPLE

select bd.file_id, bd.page_id, p.*
from sys.dm_os_buffer_descriptors bd
left join sys.allocation_units au
 on bd.allocation_unit_id = au.allocation_unit_id
left join sys.partitions p
  on ( au.type in (1,3) and au.container_id = p.hobt_id )
    or
     ( au.type = 2 and au.container_id = p.partition_id )
where database_id = 2

Vous pouvez également essayer de examiner quelques pages de TEMPDB pour voir si l'en-tête et les données de la page vous donnent une indication d'où ils viennent.

Answer 2

Pourriez-vous essayer cette requête et envoyer la sortie?

SET NOCOUNT ON;

SELECT
(DATEDIFF(n, dtat.transaction_begin_time, GETDATE())) as duration, *
FROM 
sys.dm_tran_active_transactions dtat 
INNER JOIN sys.dm_tran_session_transactions dtst 
ON dtat.transaction_id = dtst.transaction_id
INNER JOIN sys.dm_exec_sessions es 
ON dtst.session_id = es.session_id
WHERE es.session_id > 50 

Merci,

Crainder