Domanda

Ho una produzione "Microsoft SQL Server 2012 (SP1) - 11.0.3128.0 (X64)" che mostra i sintomi del tampone strano e dell'aspettativa di vita della pagina (PLE).

Lo sto eseguendo ogni minuto sul mio server (per tracciare questo problema):

SELECT @ple = CAST([cntr_value] AS VARCHAR(20))
FROM sys.dm_os_performance_counters
WHERE [object_name] LIKE '%Manager%'
AND [counter_name] = 'Page life expectancy'

SELECT @usedBufferPages = CAST(COUNT(*) /128 AS VARCHAR(20)) 
FROM sys.dm_os_buffer_descriptors

DECLARE @StartDate VARCHAR(8) = Convert(VARCHAR(8), GETDATE(), 14)
RAISERROR ('%s. PLE at %s and Used Buffers at %s at %s ', 0, 
            1,@runCountString ,@ple, @usedBufferPages, @StartDate) WITH NOWAIT  
.

Questo è un po 'di output di esempio:

16. PLE at 858 and Used Buffers at 7290 at 09:51:42 
17. PLE at 918 and Used Buffers at 7342 at 09:52:42 
18. PLE at 978 and Used Buffers at 7408 at 09:53:43 
19. PLE at 1039 and Used Buffers at 7547 at 09:54:43 
20. PLE at 1100 and Used Buffers at 7697 at 09:55:44 
21. PLE at 1160 and Used Buffers at 7901 at 09:56:45 
22. PLE at 1221 and Used Buffers at 7961 at 09:57:46 
23. PLE at 1282 and Used Buffers at 8012 at 09:58:46 
24. PLE at 11 and Used Buffers at 313 at 09:59:46 
25. PLE at 31 and Used Buffers at 966 at 10:00:46 
26. PLE at 90 and Used Buffers at 1580 at 10:01:47 
27. PLE at 151 and Used Buffers at 3072 at 10:02:47 
28. PLE at 211 and Used Buffers at 3152 at 10:03:47 
29. PLE at 271 and Used Buffers at 3729 at 10:04:47  
.

All'articolo # 24 SQL Server riporta il PLe da 1.282 a 11 . SQL Server segnala anche che i buffer usati vanno da 8.012 a 313 .

Prima ho cercato le scarse query da corsa, e ne ho trovata alcuni fissi (non ha avuto alcun effetto sulla questione). Ma non sto trovando alcun problema le query che sono correlate ai tempi in cui ho problemi di Ple / Buffer. Inoltre, se fosse una query scarsa da corsa, allora penserei che i buffer sarebbero pieni di tali dati di query, non vuoti / mancanti / errati.

Avanti ho pensato che la macchina virtuale stia ricevendo la sua memoria quando è successo. Ma ho chiesto al mio sistema admin e mi assicura che la memoria non sia dinamica o condivisa in alcun modo. (Quello che viene assegnato, ottiene, tutto il tempo.) Inoltre, eseguo questa scrittura ogni 10 minuti e quando il PLE riporta meno di 50:

  SELECT * FROM sys.dm_os_sys_memory
.

E segnala gli stessi valori / simili quando i PLe / buffer sono alti e quando sono bassi. Per completezza, ecco un esempio dei valori prima e dopo # 24 sopra:

total_physical_memory_kb    available_physical_memory_kb    total_page_file_kb  available_page_file_kb  system_cache_kb kernel_paged_pool_kb    kernel_nonpaged_pool_kb   system_high_memory_signal_state   system_low_memory_signal_state   system_memory_state_desc
20970996                    4758672                         24378868            7929404                 4844160         686076                  182752                    1                                 0                                Available physical memory is high
20970996                    4743468                         24378868            7892632                 4845000         686580                  182688                    1                                 0                                Available physical memory is high
.

Ho controllato la sessione sanitaria del sistema e non mostra nulla di relativo. (Tutto ciò che è impersonolato FALURES, e i loro tempi non sono correlati con i tempi che i PLe / buffer mostrano problemi.

Ho tracciato quanto spesso si verifica, non riesco a vedere un modello o collegarlo a qualsiasi lavoro o attività pianificate.

Ecco un grafico che mostra PLE e buffer oltre 21 ore:

 PLE e buffer oltre 21 ore

Quindi sono scatenato. Penso che il nucleo del problema sia i tamponi non il ple. (Penso che Ple stia ottenendo un falso rapporto di basso perché tutti i buffer sono in qualche modo spariti.)

Ma non riesco a pensare a nessun modo in cui questo potrebbe accadere. O cosa fare dopo.

Mi piacerebbe consiglio su ulteriori cose da verificare o suggerire di ciò che questo problema potrebbe essere.

Aggiornamenti da domande nei commenti:

quindi, quanta memoria è data il server? La VM ha 20 GB di memoria.

Cos'è la memoria del server MAX?

name                    value   value_in_use  description
max server memory (MB)  13000   13000         Maximum size of server memory (MB)
min server memory (MB)  0       16            Minimum size of server memory (MB)
.

Nota: ho fatto un po 'di lettura su questo solo ora, e sembra che queste impostazioni siano sbagliate per il mio server.

Quanto è grande il database? Esistono due database transazionali in esecuzione su questo server (sono in procinto di ottenere server per isolarli). Le loro dimensioni sono 383 GB e 378 GB.

Quali altre applicazioni e servizi sono in esecuzione su quel server? Questo server ospita i dati per la mia applicazione. Non ci sono altre cose che lo colpiscono. (Ho un archivio operativo operativo replicato per i report e tali.

Qual è la tecnologia VM VM Ware.
è questo VM in esecuzione su un host che ospita solo VMS con allocazione di risorse simili? abbiamo molti VMS alla nostra azienda. Tutte le dimensioni variabili. Questo è uno dei più grandi però.

Puoi confermare ciò che il tuo amministratore di sistema ti sta parlando della memory assegnazione senza solo doverlo credergli? non posso. Non ho accesso a quegli strumenti.

(Nella mia esperienza, gli amministratori del sistema diranno molte cose per passare il dollaro e incolpare l'app o chiunque altro se significhi che non devono fare nulla.) Posso completamente capire quel sentimento.

Quel modello sembra certamente grave pressione di memoria sono d'accordo. Speravo di trovare qualcosa per dimostrare che SQL si sente la pressione della memoria. Quindi posso rimandarlo agli amministratori del sistema per ulteriori ricerche.

Statistiche del tempo di attesa

WaitType               Wait_S      Resource_S  Signal_S  WaitCount  Percentage   AvgWait_S  AvgRes_S  AvgSig_S 
---------------------- ----------- ----------- --------- ---------- ------------ ---------- --------- ---------
PAGEIOLATCH_SH         16250.10    16219.14    30.96     2171649    29.59        0.0075     0.0075    0.0000   
CXPACKET               14214.03    13238.56    975.47    1187935    25.88        0.0120     0.0111    0.0008   
PAGEIOLATCH_EX         6814.59     6806.21     8.38      638725     12.41        0.0107     0.0107    0.0000   
WRITELOG               5157.42     4873.44     283.98    3588476    9.39         0.0014     0.0014    0.0001   
BACKUPIO               2569.51     2538.12     31.39     1704119    4.68         0.0015     0.0015    0.0000   
LCK_M_IX               2477.15     2477.10     0.05      113        4.51         21.9217    21.9213   0.0004   
ASYNC_IO_COMPLETION    2079.99     2079.66     0.33      836        3.79         2.4880     2.4876    0.0004   
BACKUPBUFFER           1807.75     1759.11     48.64     380189     3.29         0.0048     0.0046    0.0001   
IO_COMPLETION          986.23      985.84      0.39      116112     1.80         0.0085     0.0085    0.0000   
.

È stato utile?

Soluzione

Come discusso su questo thread SE e confermato da op.

.

Il problema è dovuto a Bug in SQL Server 2012. THS Bug è stato fissato in SQL Server 2012 SP1 CU4 .O per essere su Safer ha detto che ti consiglierei di applicare SQL Server 2012SP2 invece di andare per CU4.

Come da Microsoft Bug Fix Detail

.

È possibile che si verifichi prestazioni lente in SQL Server 2012. Quando si controlla Strumenti di monitoraggio delle prestazioni di SQL Server, si vede quanto segue:

• Un rapido declino del SQLServer: Gestore buffer \ Aspettativa di vita della pagina Valori contatore delle prestazioni.Quando si verifica questo problema, il contatore è Vicino a 0.

Altri suggerimenti

Il pool del buffer è solo 13 GB e i tuoi database sono 383 GB e 378 GB che hai classificato come OLTP - piccole transazioni in esecuzione troppo frequentemente.

La situazione di cui sopra, se devo immaginare è come sotto:

 Inserisci la descrizione dell'immagine qui (fonte: Foto di Google)

Devi capire come SQL Server memorizza le informazioni:

.

SQL Server memorizza le informazioni in memoria in una struttura chiamata cache di memoria. Le informazioni nella cache possono essere dati, voci di indicizzazione, piani di procedura compilati e una varietà di altri tipi di informazioni di SQL Server. Per evitare di ri-creare le informazioni, viene mantenuta la cache di memoria a lungo Il più possibile ed è ordinariamente rimosso dalla cache quando è troppo vecchio per essere utile o quando lo spazio di memoria è necessario per nuove informazioni. Il processo che rimuove le vecchie informazioni è chiamato sweep a memoria. Lo sweep Memory è un'attività frequente, ma non è continua.

Sei sicuro che si verifichi la memoria di memoria a causa della quantità di dimensioni del database e della quantità di buffer inadeguata. Fare riferimento a - Come determinare la memoria ideale per esempio?

Raccogli Aspetta Statistiche e Controllare le prestazioni Problemi che derivano dalla memoria del pool di buffer sprecato

Raccomandazione:

Aggiungi più memoria all'istanza del server e separare i due database su diversi VM con memoria adeguata.

C'è molto poco da eseguire il debug qui - è necessario aggiungere memoria, dividere logicamente il database su più VMS o capire che la mischia che devi fare con la memoria limitata porterà a problemi di prestazioni e PLE volatili.Cercando di adattarsi a 800 GB di dati in 13 GB di memoria è come cercare di riporre in uno zaino.

guarda più vicino alle domande che vengono eseguite.L'utilizzo della memoria da solo sui database è normalmente troppo grossolano una metrica per migliorare le cose.Supponendo che non sia possibile influire sulle query (applicazione Black Box), vale ancora la pena di capire cosa sta influenzando l'utilizzo della memoria.Ad esempio, un processo batch potrebbe andare a utilizzare tutto lo spazio del buffer in un singolo colpo interrogando tutti i dati su un tavolo massiccio.

In particolare cerca eventuali indici mancanti che causano scansioni complete della tabella - poiché possono graffiare efficacemente la cache sul server.

SQL Server ha un'eccellente serie di strumenti di analizzatore che possono monitorarlo in tempo reale, e sospetto che vedrai qualcosa che sporgesse come un pollice di dolore una volta che lo si approfondisca.

Non che sto suggerendo di cambiare lo schema del database, ma una cosa da cercare è eccessivamente grandi campi di varchar - possono davvero aspirare lo spazio della cache su un grande database.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a dba.stackexchange
scroll top