Hjälp att felsöka SqlException:Timeout gick ut vid anslutning, i en situation utan belastning

Inte tillräckligt med minne

Detta är mycket troligt ett minnesproblem, kanske förvärrat eller utlöst av andra saker, men fortfarande ett minnesproblem. det finns två andra (mindre sannolika) möjligheter som du bör kontrollera och eliminera först (eftersom det är lätt att göra det):

Enkla att kontrollera möjligheter:

1. Du kanske har "Autostängning" aktiverat:Autostängning kan ha exakt detta beteende, men det är sällsynt att det aktiveras. För att kontrollera detta, högerklicka i SSMS på din applikationsdatabas, välj "Egenskaper" och välj sedan rutan "Alternativ". Titta på posten "Auto Stäng" och se till att den är inställd på False. Kontrollera även tempdb.

2. SQL Agent Jobs kan orsaka det:Kontrollera agentens historiklogg för att se om det fanns några jobb som kördes konsekvent under händelserna. Kom ihåg att kontrollera underhållsjobb också, eftersom saker som Rebuilding Index ofta nämns som prestandaproblem medan de körs. Dessa är osannolika kandidater nu, bara för att de normalt inte skulle påverkas av Profiler.

Varför det ser ut som ett minnesproblem:

Om de inte visar något, bör du kontrollera om det finns minnesproblem. Jag misstänker Memory som orsaken i ditt fall eftersom:

• Du har 1 GB minne:Även om detta tekniskt sett är över minimum för SQL Server, är det långt under det rekommenderade för SQL Server, och långt under vad som enligt min erfarenhet är acceptabelt för produktion, även för en lätt laddad server.

• Du kör IIS och SQL Server på samma box:Detta rekommenderas inte i sig, till stor del på grund av påståendet om minne som resulterar, men med endast 1 GB minne resulterar det i IIS, appen, SQL Server, OS och alla andra uppgifter och/eller underhåll kämpar om väldigt lite minne. Sättet som Windows hanterar detta är att ge minne till de aktiva processerna genom att aggressivt ta bort det från de icke-aktiva processerna. Det kan ta många sekunder, eller till och med minuter för en stor process som SQL Server att få tillbaka tillräckligt med minne för att fullständigt kunna betjäna en begäran i den här situationen.

• Profiler fick 90 % av problemet att försvinna:Detta är en stor ledtråd om att minnet troligen är problemet, eftersom saker som Profiler vanligtvis har exakt denna effekt på det här problemet:Profiler-uppgiften håller SQL-servern bara lite lite aktiv hela tiden. Ofta är detta precis tillräckligt med aktivitet för att antingen hålla det borta från OS:s "rensare"-lista, eller åtminstone minska dess inverkan något.

Hur man letar efter minne som den skyldige:

1. Stäng av profileraren:Den har en Heisenberg-effekt på problemet, så du måste stänga av den annars kommer du inte att kunna se problemet på ett tillförlitligt sätt.

2. Kör en System Monitor (perfmon.exe) från en annan box, som fjärransluter till prestationsinsamlingstjänsten på boxen som din SQL Server och IIS körs på. Du kan enklast göra detta genom att först ta bort de tre standardstatistiken (de är endast lokala), och sedan lägga till den statistik som behövs (nedan), men se till att ändra datornamnet i den första rullgardinsmenyn för att ansluta till din SQL box.

3. Skicka insamlad data till en fil genom att skapa en "Counter Log" på perfmon. Om du inte är bekant med detta är det enklaste förmodligen att samla in data till en tabb- eller kommaseparerad fil som du kan öppna med Excel för att analysera.

4. Ställ in din perfmon för att samla in till en fil och lägg till följande räknare till den:

   -- Processor\%Processortid[Totalt]

   -- PhysicalDisk\% Idle Time[för varje disk ]

   -- PhysicalDisk\Avg. Diskkölängd[för varje disk ]

   -- Minne\Sidor/sek

   -- Minne\Sidläsning/sek

   -- Minne\Available MBytes

   -- Nätverksgränssnitt\Bytes totalt/sek[för varje gränssnitt som används ]

   -- Process\% processortid[se nedan ]

   -- Process\Page Faults/sek[se nedan ]

   -- Process\Working Set [se nedan ]

5. För processräknare (ovan) vill du inkludera sqlserver.exe-processen, alla IIS-processer och alla stabila applikationsprocesser. Observera att detta ENDAST kommer att fungera för "stabila" processer. Processer som kontinuerligt återskapas efter behov, kan inte fångas på detta sätt eftersom det inte finns något sätt att specificera dem innan de existerar.

6. Kör den här samlingen till en fil under den tid som problemet oftast inträffar. Ställ in uppsamlingsintervallet till något nära 10-15 sekunder. (detta samlar in mycket data, men du kommer att behöva denna upplösning för att välja ut de separata händelserna).

7. När du har en eller flera incidenter, stoppa insamlingen och öppna sedan din insamlade datafil med Excel. Du kommer förmodligen att behöva formatera om tidsstämpelkolumnen för att vara användbar synlig och visa timmar minuter och sekunder. Använd din IIS-logg för att hitta den exakta tidpunkten för incidenterna, titta sedan på perfmondata för att se vad som pågick före och efter incidenten. I synnerhet vill du se om dess arbetsuppsättning var liten innan och var stor efter, med en hel del sidfel däremellan. Det är det tydligaste tecknet på detta problem.

LÖSNINGAR:

Separera antingen IIS och SQL Server i två olika boxar (föredraget) eller så lägg till mer minne till boxen. Jag skulle tro att 3-4 GB borde vara ett minimum.

Vad sägs om den där konstiga EF-grejen?

Problemet här är att det med största sannolikhet antingen är perifert eller bara bidrar till ditt huvudproblem. Kom ihåg att Profiler gjorde att 90 % av dina incidenter försvann, så vad som återstår kan vara ett annat problem, eller så kan det bara vara den mest extrema förvärraren av problemet. På grund av dess beteende skulle jag gissa att den antingen cyklar sin cache eller så finns det något annat bakgrundsunderhåll av applikationsserverns processer.