Sqlserver
 sql >> Database >  >> RDS >> Sqlserver

Guida alla risoluzione dei problemi SqlException:timeout scaduto alla connessione, in una situazione di non carico

Memoria insufficiente

Questo è molto probabilmente un problema di memoria, forse aggravato o innescato da altre cose, ma è comunque intrinsecamente un problema di memoria. ci sono altre due possibilità (meno probabili), che dovresti controllare ed eliminare prima (perché è facile farlo):

Possibilità facili da verificare:

  1. Potresti avere "Chiusura automatica" abilitata:la chiusura automatica può avere esattamente questo comportamento, tuttavia è raro che venga attivata. Per verificarlo, in SSMS fai clic con il pulsante destro del mouse sul database dell'applicazione, seleziona "Proprietà" e quindi seleziona il riquadro "Opzioni". Guarda la voce "Chiusura automatica" e assicurati che sia impostata su False. Controlla anche tempdb.

  2. La causa potrebbe essere causata dai processi dell'agente SQL:controllare il registro della cronologia dell'agente per verificare se sono presenti processi in esecuzione in modo coerente durante gli eventi. Ricorda di controllare anche i lavori di manutenzione, poiché cose come la ricostruzione degli indici sono spesso citate come problemi di prestazioni mentre sono in esecuzione. Questi sono candidati improbabili ora, solo perché normalmente non sarebbero influenzati dal Profiler.

Perché sembra un problema di memoria:

Se quelli non mostrano nulla, dovresti verificare la presenza di problemi di memoria. Sospetto che la memoria sia la causa nel tuo caso perché:

  • Hai 1 GB di memoria:sebbene questo sia tecnicamente al di sopra del minimo per SQL Server, è molto al di sotto di quello consigliato per SQL Server e molto al di sotto di quello che nella mia esperienza è accettabile per la produzione, anche per un server leggermente caricato.

  • Stai eseguendo IIS e SQL Server nella stessa casella:questo non è consigliato di per sé, in gran parte a causa della contesa per la memoria che ne risulta, ma con solo 1 GB di memoria risulta in IIS, l'app, SQL Server, il Il sistema operativo e qualsiasi altra attività e/o manutenzione lottano per avere pochissima memoria. Il modo in cui Windows lo gestisce è fornire memoria ai processi attivi sottraendola in modo aggressivo ai processi non attivi. Possono essere necessari molti secondi o addirittura minuti prima che un processo di grandi dimensioni come SQL Server riesca a recuperare memoria sufficiente per essere in grado di soddisfare completamente una richiesta in questa situazione.

  • Profiler ha risolto il 90% del problema:questo è un grande indizio del fatto che probabilmente la memoria è il problema, perché in genere cose come Profiler hanno esattamente questo effetto su questo particolare problema:l'attività Profiler mantiene SQL Server solo un poco bit attivo tutto il tempo. Spesso, questa è un'attività sufficiente per tenerlo fuori dall'elenco degli "scavenger" del sistema operativo, o almeno per ridurne un po' l'impatto.

Come controllare la memoria come colpevole:

  1. Spegni il Profiler:ha un effetto Heisenberg sul problema, quindi devi disattivarlo o non sarai in grado di vedere il problema in modo affidabile.

  2. Eseguire un monitor di sistema (perfmon.exe) da un'altra casella, che si connette in remoto al servizio di raccolta delle prestazioni sulla casella su cui sono in esecuzione SQL Server e IIS. puoi farlo più facilmente rimuovendo prima le tre statistiche predefinite (sono solo locali), quindi aggiungi le statistiche necessarie (sotto), ma assicurati di cambiare il nome del computer nel primo menu a discesa per connetterti al tuo SQL casella.

  3. Invia i dati raccolti a un file creando un "Contatore Log" su perfmon. Se non hai familiarità con questo, la cosa più semplice da fare è probabilmente raccogliere i dati in un file separato da tabulazioni o virgole che puoi aprire con Excel per analizzare.

  4. Configura la tua perfmon per raccogliere in un file e aggiungi i seguenti contatori:

    -- Processore\%Tempo processore[Totale]

    -- PhysicalDisk\% Tempo di inattività[per ogni disco ]

    --Disco fisico\Media Lunghezza della coda del disco[per ogni disco ]

    -- Memoria\Pagine/sec

    -- Memoria\Letture pagine/sec

    -- Memoria\MByte disponibili

    -- Interfaccia di rete\Totale byte/sec[per ogni interfaccia in uso ]

    -- Processo\% Tempo di elaborazione[vedi sotto ]

    -- Processo\Errori di pagina/sec[vedi sotto ]

    -- Processo\Set di lavoro [vedi sotto ]

  5. Per i contatori di processo (sopra) si desidera includere il processo sqlserver.exe, qualsiasi processo IIS e qualsiasi processo dell'applicazione stabile. Si noti che questo funzionerà SOLO per processi "stabili". I processi che vengono continuamente ricreati secondo necessità, non possono essere acquisiti in questo modo perché non è possibile specificarli prima che esistano.

  6. Esegui questa raccolta in un file durante il periodo in cui il problema si verifica più frequentemente. Impostare l'intervallo di raccolta su qualcosa di vicino a 10-15 secondi. (questo raccoglie molti dati, ma avrai bisogno di questa risoluzione per selezionare gli eventi separati).

  7. Dopo aver riscontrato uno o più incidenti, interrompere la raccolta e quindi aprire il file di dati raccolto con Excel. Probabilmente dovrai riformattare la colonna timestamp per essere utilmente visibile e mostrare ore minuti e secondi. Usa il tuo registro IIS per trovare l'ora esatta degli incidenti, quindi guarda i dati perfmon per vedere cosa stava succedendo prima e dopo l'incidente. In particolare, vuoi vedere se il suo working set era piccolo prima ed era grande dopo, con molti errori di pagina nel mezzo. Questo è il segno più evidente di questo problema.

SOLUZIONI:

Separare IIS e SQL Server in due caselle diverse (preferito) oppure aggiungere più memoria alla casella. Direi che 3-4 GB dovrebbero essere un minimo.

Che ne dici di quella strana roba EF?

Il problema qui è che molto probabilmente è periferico o contribuisce solo al tuo problema principale. Ricorda che Profiler ha eliminato il 90% dei tuoi incidenti, quindi ciò che resta, può essere un problema diverso, o potrebbe essere solo l'aggravatore più estremo del problema. A causa del suo comportamento, immagino che stia eseguendo il ciclo della cache o che sia presente qualche altra manutenzione in background dei processi del server delle applicazioni.