Articles

SQL: ASPETTATIVA DI VITA DELLA PAGINA

Posted by admin

Sintomi: SQL ha rilevato un calo dell’aspettativa di vita della pagina, producendo risposte più lente.

Impatto: Medio

Le risposte SQL lente degraderanno l’esperienza utente, con conseguente scarsa efficienza delle operazioni dell’organizzazione.

Comportamento previsto:

Più a lungo una pagina può rimanere nel pool di buffer ed essere letta dalla memoria migliori sono le prestazioni del sistema. Si consiglia di impostare il valore di soglia a 300 secondi per ogni 4 GB di memoria buffer pool (BP).

Possibili cause di PLE (Persistent Low Page Life Expectancy)

Bassa potenza della CPU Priorità: Media
Azione consigliata:
L’utilizzo continuo associato a PLE basso può indicare la necessità di un aggiornamento della CPU o l’aggiunta di più processori. Vedi la nostra spiegazione dell’utilizzo della CPU qui
In alternativa, un alto tasso di utilizzo della CPU può indicare un’applicazione o un codice SQL mal sintonizzati. L’ottimizzazione dell’applicazione può ridurre l’utilizzo della CPU.

Priorità RAM insufficiente: Media
Rivedere la quantità di RAM totale allocata a SQL (pur mantenendo RAM sufficiente per le esigenze del sistema operativo). Confronta il rapporto tra memoria SQL e dimensione del database-in base alla nostra esperienza, un rapporto tra RAM totale superiore al 20% del database più grande è ottimale.
Azione consigliata:
Se possibile, allocare più memoria a SQL o in alternativa aggiungere RAM fisica al server e aumentare l’allocazione della memoria SQL.

File di pagina occupato/lento Priorità: bassa
Controlla cos’altro è in esecuzione che potrebbe rallentare la velocità di accesso al disco. Il pool di buffer scambia le pagine su disco quando è necessario spazio di memoria. Questo processo dipende fortemente dall’efficienza delle azioni di lettura/scrittura dei dati sul disco rigido e dal livello della domanda.
Azione consigliata:
Per accelerare l’I/O del disco e ridurre la latenza, individuare il file di paging sull’unità più veloce disponibile (o eseguire l’aggiornamento a un hardware più efficiente). Inoltre, ridurre la concorrenza per questa risorsa da altre operazioni. AimBetter resource monitor fornisce statistiche complete sullo spazio totale su disco, spazio libero e attività del file di pagina.

Priorità di allocazione del pool di buffer errata: Basso
In SQL Server, i dati vengono memorizzati in pagine da 8 KB. Quando i dati sono necessari per l’input / output, la pagina viene prima letta dal disco e archiviata in memoria. L’area allocata è chiamata Pool di buffer. Una volta che una pagina viene caricata nel pool, tutti gli accessi successivi sono molto veloci ed efficienti, mentre l’I/O del disco è relativamente lento. Quanta più memoria possibile dovrebbe essere allocata al pool di buffer, senza affamare il sistema operativo.
Azione consigliata:
Allocare la proporzione ottimale di RAM fisica a BP, ma lasciare RAM sufficiente per le operazioni del sistema operativo. Impostare un valore nell’opzione Memoria server massima della pagina ‘Opzioni memoria server’, che lascia abbastanza memoria per il sistema operativo stesso. Raccomandiamo circa 4 GB in meno rispetto alla quantità totale di RAM installata

Possibili cause o transitori low Page Life Expectability (PLE)

Indice mancante o danneggiato Priorità: Alto
Gli indici mancanti indicano che SQL Server suggerisce che la query potrebbe funzionare più velocemente con un indice. 99% del tempo, la corruzione è disco o driver del disco/firmware correlati.
Azione consigliata:
In caso di indice mancante, fare riferimento al team di progettazione del sistema.
In caso di indici danneggiati, consultare il team di gestione dello storage o i nostri esperti di supporto. Un possibile rimedio nei casi in cui la corruzione si sta ripetendo è quello di clonare il database su una nuova configurazione hardware.

Problemi di codifica Priorità: bassa
Forse il risultato di problemi come piani di query inefficienti o standard di codifica impropri.
Azione consigliata:
Controllare il piano che SQL stava utilizzando, per determinare se era ottimale.
Esaminare le query del database per verificare se le query di dati richieste sono danneggiate o non corrette.
Indagare la codifica, in modo da vedere se l’efficienza può essere migliorata.

Query che saturano la priorità del pool di buffer: bassa
Queste cause non persistono per lunghi periodi. Le cause principali sono:

  • ottenere grandi sovvenzioni di memoria
  • spostando un gran numero di pagine in memoria con nuove
  • modificando molte pagine, costringendole a essere scaricate su disco
  • molte query simultanee (o alcune molto grandi)

Azione consigliata :
Nei casi in cui si verificano nuovamente o mostrano una tendenza ad aumentare di grandezza (PLE inferiore), indagare le altre possibili cause di seguito.

DBCC CHECKDB Priorità di esecuzione: bassa
CHECKDB è molto intensivo di risorse-probabilmente una delle cose che SQL Server esegue con maggiore intensità di risorse. L’introduzione di questo processo come carico IO aggiuntivo rispetto al normale carico di SQL Server significa che le teste del disco si muoveranno costantemente.
Azione consigliata :
Si consiglia di eseguire qualsiasi processo CHECKDB essenziale in un momento di carico minimo di SQL Server, o in alternativa su copie di backup dei database offline.

Index Ricostruisce Priorità in esecuzione: Bassa
Un’operazione di ricostruzione dell’indice crea sempre un nuovo indice, il che significa che è necessario spazio extra per costruire il nuovo indice prima di eliminare quello vecchio; sono necessarie molte risorse di CPU e I/O, che possono sovraccaricare il sistema.
Azione consigliata :
Se si verifica frequentemente, può essere corretto da cambiamenti nella procedura di indicizzazione, ad esempio passando a una strategia in cui la frammentazione viene analizzata ogni notte e vengono elaborati solo gli indici frammentati. I nostri consulenti esperti del team di supporto sono disponibili per analizzare e assistere.

Sfondo

La metrica dell’aspettativa di vita della pagina misura il numero medio di secondi in cui le pagine rimangono nel pool di buffer. È strettamente correlato all’utilizzo del file di pagina – vedi qui.
Per prestazioni ottimali, i dati devono essere letti dalla memoria piuttosto che dal disco, che è molto più lento. SQL raggiunge questo utilizzando pagine di memoria che memorizzano i dati più recenti. Un’area riservata di memoria (il pool di buffer) è disponibile per la memorizzazione di queste pagine. Quando il pool di buffer è pieno e SQL richiede nuovo spazio, il server scambia la pagina più vecchia nel file di pagina sul disco e legge i nuovi dati. L’aumento del numero di swap tra memoria e disco influisce direttamente sulle prestazioni.
Bassi livelli sostenuti di PLE è un indicatore affidabile della pressione della memoria di SQL Server. Questa pressione può essere un risultato di elevata domanda, o da inefficiente organizzazione di dati, sia fisica che logica
Si consiglia di impostare il valore di soglia a 300 secondi per ogni 4 GB di Pool di Buffer (BP) di memoria sul server, il che significa che il server deve mantenere qualsiasi pagina in memoria (dopo un processo di riferimenti alla pagina del pool di buffer per minimo 5 minuti prima che viene scaricata su disco. Se il pool di buffer sta svuotando le pagine in meno di 300 secondi, probabilmente c’è un problema.
Più memoria ha il server, più disco memorizzato nella cache legge e scrive che può eseguire. La mancanza di memoria di sistema può causare alte letture e scritture del disco non memorizzate nella cache. L’aggiunta di memoria al server può aiutare a ridurre l’accesso al disco fisico.

Related Post

Leave A Comment