prestazioni della concorrenza del server sql

Abbiamo riscontrato alcuni problemi di prestazioni nel nostro ambiente di produzione.

abbiamo scoperto che quando le sessioni attive superano i 25, l'utilizzo della CPU arriva al 100% e impiega molto tempo a scendere.

L'ambiente che abbiamo:

Prodotto Microsoft SQL Server Enterprise Edition 9.3 (sp2)

CPU 2 (Xeon 2.13)

Memoria 7G

istantanea dei dettagli della sessione 1

Sessioni attive 25

Transazioni attive 496

Sessioni inattive 289

Transazioni bloccate 29

istantanea del dettaglio della sessione2

Sessioni attive 59

Transazioni attive 885

Sessioni inattive 267

Transazioni bloccate 49

Mi piacerebbe sapere

1. se 2CPU possono gestire bene 25 sessioni attive (500 transazioni attive) .PS: abbiamo testato che senza una richiesta di concorrenza, una transazione, che legge / scrive 5 tabelle, richiede circa 1 secondo a livello di applicazione.

2. se le transazioni bloccate richiedono più utilizzo della CPU. PS: le transazioni bloccate sono principalmente dovute a blocchi su 2 tabelle.

qual è la soluzione: aggiungere CPU? o l'applicazione di ottimizzazione (java / ibernazione) per abbreviare questa transazione e ridurre i blocchi sul tavolo?

Le tue opzioni per avere una buona immagine della situazione quando tutto striscia:

• utilizzare le tracce lato server per visualizzare le sessioni più lunghe e pesanti
• usa la procedura memorizzata Who is Active di Adam Machanic - per salvare le informazioni dei momenti in cui il server è caricato - fantastico script gratuito
• usa Activity Monitor da Management Studio solo per avere uno sguardo visivo (Cpu e IO sono quelli che ho trovato più utili) - un ottimo strumento incluso in Management Studio
• usa uno strumento gratuito di terze parti - Confio Ignite Free - che è ottimo per i momenti in cui tutto è lento e devi vedere i dettagli sulle statistiche di attesa, bloccando ... ecc - fantastico strumento gratuito
• controlla le statistiche per essere aggiornato
• controlla se gli indici sono frammentati e, in tal caso, deframmentali
• seguire gli altri consigli per la verifica degli indici mancanti, progettazione
• controlla la possibilità di utilizzare il livello di isolamento dello snapshot nel tuo database (hai un alto blocco, quindi è bello vedere se hai davvero bisogno del tuo attuale livello di isolamento)

E buona fortuna per indagare sui problemi :-).

Molto probabilmente il tuo problema è la scarsa prestazione della query causata da

• design scadente
• scarsa indicizzazione

I blocchi / blocchi derivano da una cattiva indicizzazione a causa di tutto il tempo trascorso dalla scansione delle tabelle alla fine. La CPU è irrilevante qui.

Come soluzione rapida, controlla gli indici mancanti usando le informazioni in questo articolo: http://blogs.msdn.com/b/bartd/archive/2007/07/19/are-you-using-sql-s-missing- index-dmvs.aspx

Sono d'accordo con GBN e Marian.

Per rispondere alla tua domanda relativa a 2 CPU che gestiscono 25 richieste: Ho un sistema a 2 CPU che supporta circa 750 connessioni utente e una media corrente di richieste batch 4K al secondo. Diversi elementi sono importanti per me: progettazione, gestione e messa a punto. Se inizi con una progettazione scadente dell'applicazione e del database, non riuscirai al caricamento (pensa al ridimensionamento).

Una CPU elevata può indicare una pressione della memoria. Si menziona che sono disponibili solo 7 GB di memoria per SQL Server. Se si dispone di indici con prestazioni scarse (troppi indici, indici errati o nessun indice), ciò farà sì che il sistema inserisca più memoria del database in memoria per varie richieste, quindi se vi sono indici appropriati. Vorrei mettere in guardia la creazione selvaggia di indici poiché anche quelli sbagliati ti danneggeranno poiché ognuno ha il potenziale per richiedere un aggiornamento nel corso di un'operazione di aggiornamento di riga (Crea-Aggiorna-Elimina).

Inoltre, per utilizzare i DMV dell'indice mancante è necessario utilizzare ciò che si conosce dell'applicazione e del database e non solo implementare ciascun indice consigliato. Vorrei controllare le voci del blog di Kimberly Tripp riguardanti gli indici qui . Dopo la sezione Indice, guardare le altre categorie potrebbe essere utile per la tua situazione.

Se l'aggiornamento Java / Hibernate di 5 tabelle in una singola transazione sta eseguendo gli aggiornamenti tramite più round-trip al database, allora ti stai lasciando aperto alla contesa (richieste CRUD bloccate). Il problema peggiora se l'applicazione non è in grado di tornare al database in modo tempestivo. Durante l'applicazione, la transazione attiva associata potrebbe bloccare l'elaborazione di altre richieste e causare timeout delle richieste.

Aggiungi insieme i due problemi precedenti e inizi ad avere un brutto caso di mal di testa da prestazione.

Ridurre il numero di round trip del database nel contesto di una singola transazione sarebbe un'ottima cosa da perseguire. Forse una procedura memorizzata sarebbe di aiuto.

Il resto richiederà lavoro per ridimensionare l'applicazione. Potresti anche prendere in considerazione la memoria, ma ciò dovrebbe avvenire dopo aver effettuato una revisione del design e delle prestazioni e le modifiche necessarie implementate con l'aggiunta immediata di memoria maschereranno i tuoi problemi.

Segui assolutamente i suggerimenti che Marian ha delineato.

Direi che ti sei trovato una sfida meravigliosa e ti auguro un grande successo!

1. Nella mia esperienza abbiamo MS SQL Server 2000 con 2 CPU e più di 30 sessioni attive e più di 1000 transazioni. Era difficile da server, ma ha funzionato.
2. Non sono sicuro che i blocchi utilizzino più CPU. A mio avviso, i blocchi e l'utilizzo della CPU sono due diversi problemi di prestazioni.

Per quanto riguarda la soluzione, prima devi assicurarti che il tuo problema principale sia la CPU. Prova a leggere questo problema per trovare l'origine dei tuoi problemi e ottenere la soluzione appropriata. Alla fine, se puoi rendere la tua transazione il più piccola possibile, fallo.

I miei primi pensieri sono di ridurre il numero di transazioni e la quantità di blocco. Puoi dividere alcune delle transazioni in più bit? Puoi estrarre alcune delle query dalle transazioni? Come accennato da Alex_l, la transazione più piccola possibile è l'ideale qui.

Sono d'accordo con gbn, anche l'aggiunta di indici potrebbe aiutare.

Un altro pensiero è che darei anche un'occhiata alle tue serrature. Stai eliminando i blocchi a livello di tabella quando aggiorni solo una singola riga? Potresti considerare di suggerire un blocco a livello di riga a SQL Server. Ciò risolverebbe molti problemi. (Certo, se hai 5 tavoli, probabilmente non è così, ma solo un pensiero.)

Infine, darei un'occhiata ai tuoi tavoli che stai utilizzando. Se tutti stanno bloccando una determinata tabella, puoi spostare la logica per quella tabella alla fine della transazione? Se riesci a ridurre il tempo in cui tieni un lucchetto su quella tabella molto richiesta, potrebbe essere d'aiuto.