L'aspettativa di vita della pagina di SQL Server 2012 si reimposta su 0 dopo circa 50 giorni


12

Ho notato un comportamento strano su un cluster HA a 2 server e speravo che qualcuno potesse confermare il mio sospetto o forse offrire qualche altra spiegazione ... Ecco la mia configurazione:

  • Un'installazione di SQL 2012 SP1 a 2 server
  • SQL AlwaysOn HA è stato abilitato per alcuni database
  • Le CPU sono 2,4 GHz, 4 core
  • La RAM è di 34 GB (è un'istanza AWS, quindi il numero dispari)
  • L'utilizzo delle risorse è relativamente basso: ogni server ha 14+ GB di memoria libera e SQL non è limitato alla quantità di memoria da utilizzare
  • Il tempo di accesso al disco va bene - raramente supera i 15ms / Leggi o Scrivi
  • I database non sono grandi: 1 GB, 1,5 GB, 7,5 GB
  • Il processo del server SQL utilizza 16 GB Private Bytes, 15 GB Working Set

Nel complesso, non vengono rilevati problemi di risorse. Ora per la parte dispari. SQL non viene riavviato (il processo è in esecuzione da quasi 6 mesi) ma sembra che ogni ~ 50 giorni, il contatore dell'aspettativa di vita della pagina scenda a (quasi) 0. Fino a quel punto si arrampica costantemente, senza cadere. Ecco un grafico perfetto:

inserisci qui la descrizione dell'immagine

Quando guardo i dati del contatore (non ho il numero esatto, solo un'aggregazione oraria) sembra che il valore del contatore PLE raggiunga circa 4.295.000 sec (circa 50 giorni) ogni volta (almeno ogni volta che ho dati per).

La mia folle teoria è che il numero PLE è tenuto come millisecondi come un long int senza segno (che ha un limite di 4.294.967.295) e a 49.71 giorni si reimposta, sia in base alla progettazione, sia a causa di un bug. Ciò spiegherebbe il comportamento dei due server e lo stesso modello che hanno. Oppure potrebbe essere qualcosa di completamente diverso e non ho proprio alcun senso. :)

Qualcuno ha visto qualcosa del genere o può spiegare questo comportamento?

PS Ho visto questo post, ma il mio caso sembra leggermente diverso.

PPS Questo è un repost - inizialmente l'ho pubblicato qui , ma mi è stato consigliato che il pubblico qui è più appropriato.

Grazie!


I commenti non sono per una discussione estesa; questa conversazione è stata spostata in chat .
Paul White 9

Risposte:


3

Ho visto questo comportamento su un sito client con SQL2012 SP1. I dettagli qui erano NUMA e PLE che dimostravano uno schema a "dente di sega" ma su un ciclo orario.

Un paio di thread su SQLServerCentral discussi intorno a questo:

http://www.sqlservercentral.com/Forums/Topic1415833-2799-1.aspx http://www.sqlservercentral.com/Forums/Topic1424826-2799-1.aspx

il risultato finale è che l'applicazione di SP1 CU4 sembrava risolvere il problema.

CU4 contiene la correzione dall'aspetto innocente È disponibile un aggiornamento per la gestione della memoria di SQL Server 2012 KB2845380

Vale la pena provare?


Grazie per aver pubblicato questo (scusate la risposta ritardata, per qualche motivo non ho mai ricevuto la notifica del vostro post). Ho dato un'occhiata ai link: sembrano in qualche modo simili, quindi proverò a duplicare l'installazione in QA, applicare CU4 (o probabilmente anche andare direttamente a SP2), quindi ricontrollare. Con il ritmo che vedo questo (ogni 50 giorni) ci vorrà un po 'prima che io possa confermare, ma posterò quando avrò i risultati. A proposito, i miei schemi sono ancora validi - salita costante per ~ 50 giorni, poi forte calo a ~ 0 e salita di nuovo - totale di 4 da quando è iniziato il servizio a dicembre.
CRCerr0r,

Aggiornamento ... L'ho confermato nel nostro ambiente QA. Le statistiche che ho ottenuto da lì sono: Totale giorni tra i ripristini - 49,71 (+/- 1 minuto); Il valore PLE massimo ha raggiunto - 4.294.961 (a campioni di 1 minuto, quindi avrebbe potuto essere leggermente più alto). Ciò conferma praticamente le osservazioni sulla produzione. Applicherò CU4 e riferirò tra ~ 50 giorni ... :)
CRCerr0r

1
Qualche novità al riguardo?
Michael Green,
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.