PageIOLatch_Sh attende notato dopo aver sintonizzato un indice

Question

Ultimamente, un sacco di query al database sono timeout. Mentre indaga ho scoperto che le query sono in stato di sospensione con wait_type come PageIOLatch_Sh. Non ho notato tante interrogazioni essere sospesi prima sul server. Questo è avvenuto per il da Sabato.

Un paio di settimane fa, la CPU sul server db era al 100% costante. Durante il tentativo di risolvere il problema che ho cambiato un paio di indici che non sono stati realmente utilizzati e sono stati conseguente a user_scans. Dopo aver modificato gli indici, l'utilizzo della CPU del server è andato giù, le prestazioni del sito è stato generalmente più veloce e guardando le statistiche dell'indice ora un numero elevato di user_seeks stesse accadendo, ho pensato che era un buon segno.

Tuttavia, ora, dopo una settimana o due, anche se l'utilizzo della CPU, non è al 100, un gran numero di query hanno iniziato timeout e vengono osservati PageIoLatch_Sh attese. La cosa interessante è che questi timeout non stavano accadendo in un momento così alta frequenza in precedenza, anche se la CPU è al 100%.

Ora il mantenimento degli indici è anche qualcosa che rallenta la lavorazione di sql server, quindi mi chiedevo se i nuovi indici poteva trasformarsi in un numero maggiore di queste attese e timeout?

Answer 1

In base alle informazioni di fondo che ci ha fornito suona come si è spostato il punto di contesa nel vostro server dalla CPU a IO, a seguito di attuare una strategia di indicizzazione mirata alla query problematiche specifiche.

Per la maggior parte (senza entrare nello specifico di che cosa esattamente la vostra strategia di indicizzazione è) questo è il comportamento previsto perché con CPU non essere più un punto di contesa, WAITS sono naturalmente presenti altrove.

I problemi di prestazioni che state vedendo ora non sono necessariamente causato dalle modifiche di indice che avete applicato. Ulteriori indagini ad identificare le query specifiche che sono responsabili per le attese IO / così come i timeout che state vedendo è richiesto. Si vuole rivedere i piani di esecuzione per ognuno di questi scenari per individuare possibili aree di ottimizzazione (aspetto per le operazioni in genere indesiderati prima come le conversioni implicite, tavolo scansioni ecc).

Non volendo essere presuntuoso però incontro spesso di query timeout su ambienti dei clienti a causa di cattive scelte piano di query a causa di sniffing dei parametri. Questo può anche essere qualcosa di esaminare.

Per alcune query comodo da usare durante le indagini voi dare un'occhiata a SQL Server query diagnostici di Glenn Berry. Ci sono un certo numero di query fantastici in là per guardare IO, ad esempio, che i database sono responsabili per la maggior IO, che i file di dati del database stanno vedendo il maggior parte delle attività, quali query causano più letture / scritture etc.

Answer 2

Supponendo che gli indici siano aggiornati, passando da 100% della CPU a qualcosa di meno, pur avendo problemi di timeout, implica che l'applicazione è ora in attesa che le serrature o per il disco. Il latch attese implicano il disco. Vorrei usare perfmon di guardare ai dischi per vedere se ci sembra che ci sia una quantità insolitamente alta di legge, sguardo ai piani di query per le query esatte che sono in esecuzione lenta e ripensare quello che ho fatto circa l'indicizzazione.

Un altro pensiero è, se ho fatto un cambiamento e le cose sembrano peggiorare in seguito, la prima cosa che vorrei fare è che il cambiamento di annullamento. IOW, mettere i vecchi indici di nuovo.

Answer 3

mi sarebbe d'accordo con John, il collo di bottiglia è appena trasferita su di voi. Si potrebbe essere colpire i limiti di hardware, o più probabilmente, la query potrebbe essere necessario un po 'di lavoro.