TempDB uses a lot of space in buffer pool

Question

I'm running a SQL Server 2014 with 2 cores and a max memory of 6GB. When I'm checking what's in the buffer pool, I see that TempDB uses 1GB of memory. That's the query I used:

SELECT COUNT(*) AS cached_pages_count ,
(count(*) * 8.0)/1024 as MB,
        CASE database_id
          WHEN 32767 THEN 'ResourceDb'
          ELSE DB_NAME(database_id)
        END AS Database_name
    FROM sys.dm_os_buffer_descriptors
    GROUP BY DB_NAME(database_id) ,
        database_id
    ORDER BY cached_pages_count DESC;

But when I check what tables are in TempDB, there are only 40 tables and they use 728KB. This is the query:

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  t.Name

I also checked sys.dm_db_session_space_usage to see if there was a session that allocated all that space in TempDB

My buffer cache is 2.2GB and almost 50% is taken by TempDB

Can someone try to explain why TempDB is so large?

UPDATE I did a DBCC PAGE of some pages found in the dm_os_buffer_descriptors and it looks like they are not allocated (GAM/SGAM Not Allocated, PFS 0_PCT_FULL)

PAGE HEADER:

Page @0x0000000DB026C000

m_pageId = (1:159735) m_headerVersion = 1
m_type = 1 m_typeFlagBits = 0x0 m_level = 0
m_flagBits = 0x20 m_objId (AllocUnitId.idObj) = -1948083318
m_indexId (AllocUnitId.idInd) = 1 Metadata: AllocUnitId = 435280365092864 Metadata: PartitionId = 0 Metadata: IndexId = -1 Metadata: ObjectId = 0 m_prevPage = (1:160115) m_nextPage = (1:160144) pminlen = 13 m_slotCnt = 217 m_freeCnt = 3406
m_freeData = 4352 m_reservedCnt = 0 m_lsn = (13668:97392:89) m_xactReserved = 0
m_xdesId = (0:0) m_ghostRecCnt = 0 m_tornBits = 0
DB Frag ID = 1

Allocation Status

GAM (1:2) = NOT ALLOCATED SGAM (1:3) = NOT ALLOCATED
PFS (1:153672) = 0x0 0_PCT_FULL DIFF (1:6) = NOT CHANGED
ML (1:7) = NOT MIN_LOGGED

Answer 1

That looks like a data page (page type=1) from a table variable or temp table (negative object id of -1948083318) in the leaf of a clustered index (indexid=1).

From the allocation information and the fact that this does not show up in your second query presumably the underlying object has been dropped. You may be able to get additional information about it, such as original object name, by looking for that allocation unit id in sys.fn_dblog if you're lucky.

If it belongs to a dropped object then one would certainly hope these pages are first candidates for putting on the free list.

However the article TempDB memory leak? and associated connect item indicate that there might be a problem in this area...