memoria utilizzata da Locks


9

Sono un po 'curioso, uno di SQL 2012 Enterprise Edition con 128 GB di RAM di database di 370 GB e crescente, quantità di memoria utilizzata dall'impiegato della memoria dei blocchi (OBJECTSTORE_LOCK_Manager) che mostra 7466016 KB. Posso anche confermare che guardando il contatore perfselect * from sys.dm_os_performance_counters where counter_name = 'Lock Memory (KB)'

Tuttavia, quando eseguo query

select count(*) from sys.dm_tran_locks

mostra solo 16 blocchi. Quindi, cosa sta usando oltre 7 GB di blocchi. C'è un modo per scoprirlo?

Significa che se una volta allocata la memoria per i blocchi SQL non l'ha ancora deallocata? Nelle ultime 1 ora non vedo il conteggio dei blocchi superiore a 500 ma la memoria dei blocchi rimane invariata.

La memoria massima del server è di 106 GB, non utilizziamo pagine di blocco in memoria e non vedo alcuna pressione della memoria o errori nel registro degli errori nelle ultime 12 ore. Il contatore MBytes disponibili mostra più di 15 GB di memoria disponibile.

Il monitor attività mostra costantemente 0 attività in attesa, quindi ovviamente nessun blocco.

Considerando che il blocco del server SQL richiede circa 100 byte di memoria 7 GB è molta memoria e sta cercando di scoprire chi lo sta utilizzando.

Eseguo una relazione principale del dashboard del server in base al conteggio dei blocchi che dice "al momento non sono in esecuzione transazioni di blocco sul sistema. Tuttavia, la memoria di blocco mostra ancora come indicato sopra. DB è più occupato durante le ore notturne.


Suggerirei di guardare system_health e RING_BUFFERS per vedere cosa sta succedendo
Kin Shah,

Risposte:


8

Il gestore dei blocchi è un percorso di codice critico super caldo (probabilmente il percorso di codice critico più caldo) che se dovesse attendere un'allocazione di memoria per ogni prestazione di blocco si accumulerebbe. Probabilmente alloca grandi blocchi di memoria e li gestisce da solo. Non sarei sorpreso se riserva anche la memoria in modo che non si esaurisca la memoria in alcuni percorsi di codice critico.


Remus, non so chi altro in questo forum conosca il lato C ++ di SQL Server quanto te. Dandoti quindi un beneficio di dubbio. :-)
SQL Learner,

7

Addendum alla risposta di @ RemusRusanu (non rientrerebbe in un commento) ...

Dato che il motore di database consentirà fino a 5000 blocchi per oggetto prima di inoltrare e tenere conto della risposta di Remus in merito alla natura critica del gestore dei blocchi, la prenotazione elevata inizia a sembrare plausibile:

5000 (blocchi) * 10 (tabelle o indici) * 96 (byte per blocco) * 1000 (query simultanee) = 4.47 GB

Vorrei ipotizzare che la prenotazione derivi da una combinazione della RAM disponibile e del carico di lavoro corrente ma non l'ho vista documentata o bloggata da nessuna parte. Potrebbe anche ipotizzare che la tua memoria da 128 GB sarebbe stata considerata generosa nel 2008 e la prenotazione da 7 GB è indicativa di aspettarsi un carico di lavoro OLTP pesante a quella dimensione.


1
La dimensione del database dovrebbe essere di 1,5 TB entro la fine dell'anno È in servizio da un paio di settimane. Il tuo tipo di calcolo ha senso.
SQL Learner

2

sys.dm_tran_lock mostra le risorse bloccate e le richieste di blocchi su risorse , non singole righe, che sono bloccate. Ogni risorsa bloccata conterrà molte righe e, possibilmente, altri oggetti, bloccati.

Restituisce informazioni sulle risorse del gestore blocchi attualmente attive. Ogni riga rappresenta una richiesta attualmente attiva al gestore blocchi per un blocco che è stato concesso o è in attesa di essere concesso.

Le colonne nel set di risultati sono divise in due gruppi principali: risorsa e richiesta. Il gruppo di risorse descrive la risorsa su cui viene effettuata la richiesta di blocco e il gruppo di richieste descrive la richiesta di blocco.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.