Hjælp til fejlfinding SqlException:Timeout udløb ved forbindelse, i en situation uden belastning

Ikke nok hukommelse

Dette er meget sandsynligt et hukommelsesproblem, måske forværret eller udløst af andre ting, men stadig i sagens natur et hukommelsesproblem. der er to andre (mindre sandsynlige) muligheder, som du bør tjekke og fjerne først (fordi det er nemt at gøre det):

Nem at tjekke muligheder:

1. Du kan have "Auto Luk" aktiveret:Auto Luk kan have præcis denne adfærd, men det er sjældent, at det er slået til. For at kontrollere dette skal du i SSMS højreklikke på din applikationsdatabase, vælge "Egenskaber" og derefter vælge ruden "Indstillinger". Se på posten "Auto Luk" og sørg for, at den er indstillet til Falsk. Tjek også tempdb.

2. SQL Agent-job kan være årsagen til det:Tjek agentens historiklog for at se, om der var nogen job, der konsekvent kørte under begivenhederne. Husk også at tjekke vedligeholdelsesjob, da ting som Rebuilding Indexes ofte nævnes som ydeevneproblemer, mens de kører. Disse er usandsynlige kandidater nu, kun fordi de normalt ikke ville blive påvirket af Profileren.

Hvorfor det ligner et hukommelsesproblem:

Hvis de ikke viser noget, skal du tjekke for hukommelsesproblemer. Jeg mistænker Memory som årsagen i dit tilfælde fordi:

• Du har 1 GB hukommelse:Selvom dette teknisk set er over minimum for SQL Server, er det langt under det anbefalede for SQL Server, og langt under, hvad der efter min erfaring er acceptabelt for produktion, selv for en let belastet server.

• Du kører IIS og SQL Server på den samme boks:Dette anbefales ikke i sig selv, for en stor del på grund af den påstand om hukommelse, der resulterer, men med kun 1 GB hukommelse resulterer det i IIS, appen, SQL Server, OS og andre opgaver og/eller vedligeholdelse kæmper alle for meget lidt hukommelse. Måden Windows klarer dette på er at give hukommelse til de aktive processer ved aggressivt at tage den væk fra de ikke-aktive processer. Det kan tage mange sekunder eller endda minutter for en stor proces som SQL Server at få nok af sin hukommelse tilbage til fuldstændig at kunne servicere en anmodning i denne situation.

• Profiler fik 90 % af problemet til at forsvinde:Dette er et stort fingerpeg om, at hukommelsen sandsynligvis er problemet, for typisk har ting som Profiler præcis denne effekt på dette særlige problem:Profiler-opgaven holder SQL Serveren kun lidt lidt aktiv hele tiden. Ofte er dette lige nok aktivitet til enten at holde det væk fra OS's "scavenger"-liste eller i det mindste reducere dets påvirkning en smule.

Sådan tjekker du for hukommelse som synderen:

1. Sluk profileren:Den har en Heisenberg-effekt på problemet, så du er nødt til at slukke for den, ellers vil du ikke kunne se problemet pålideligt.

2. Kør en System Monitor (perfmon.exe) fra en anden boks, der fjernopretter forbindelse til ydeevneindsamlingstjenesten på den boks, som din SQL Server og IIS kører på. du kan nemmest gøre dette ved først at fjerne de tre standardstatistikker (de er kun lokale), og derefter tilføje de nødvendige statistikker (nedenfor), men sørg for at ændre computernavnet i den første rullemenu for at oprette forbindelse til din SQL boks.

3. Send de indsamlede data til en fil ved at oprette en "Counter Log" på perfmon. Hvis du ikke er bekendt med dette, så er den nemmeste ting at gøre sandsynligvis at indsamle dataene til en fane- eller kommasepareret fil, som du kan åbne med Excel for at analysere.

4. Indstil din perfmon til at indsamle til en fil, og føj følgende tællere til den:

   -- Processor\%Processortid[Total]

   -- PhysicalDisk\% inaktiv tid[for hver disk ]

   -- Fysisk disk\Gns. Diskkølængde[for hver disk ]

   -- Hukommelse\Sider/sek.

   -- Hukommelse\Sidelæser/sek.

   -- Hukommelse\Available MBytes

   -- Netværksgrænseflade\Bytes i alt/sek.[for hver brugergrænseflade ]

   -- Process\% Processor Time[se nedenfor ]

   -- Proces\Sidefejl/sek.[se nedenfor ]

   -- Process\Working Set [se nedenfor ]

5. For procestællere (ovenfor) vil du inkludere sqlserver.exe-processen, alle IIS-processer og alle stabile applikationsprocesser. Bemærk, at dette KUN virker for "stabile" processer. Processer, der løbende bliver genskabt efter behov, kan ikke fanges på denne måde, fordi der ikke er nogen måde at specificere dem på, før de eksisterer.

6. Kør denne samling til en fil i det tidsrum, hvor problemet oftest opstår. Indstil opsamlingsintervallet til noget tæt på 10-15 sekunder. (dette indsamler en masse data, men du skal bruge denne opløsning for at udvælge de separate begivenheder).

7. Når du har en eller flere hændelser, skal du stoppe indsamlingen og derefter åbne din indsamlede datafil med Excel. Du bliver sandsynligvis nødt til at omformatere tidsstempelkolonnen for at være nyttigt synlig og vise timer minutter og sekunder. Brug din IIS-log til at finde det nøjagtige tidspunkt for hændelserne, og se derefter på perfmon-dataene for at se, hvad der foregik før og efter hændelsen. Især vil du se, om dets arbejdssæt var lille før og var stort efter, med en masse sidefejl imellem. Det er det klareste tegn på dette problem.

LØSNINGER:

Enten adskille IIS og SQL Server på to forskellige bokse (foretrukket), eller også tilføje mere hukommelse til boksen. Jeg vil mene, at 3-4 GB burde være et minimum.

Hvad med de mærkelige EF-ting?

Problemet her er, at det højst sandsynligt er enten perifert eller kun bidragende til dit hovedproblem. Husk, at Profiler fik 90 % af dine hændelser til at forsvinde, så hvad der er tilbage, kan være et andet problem, eller det kan kun være den mest ekstreme forværre af problemet. På grund af dens opførsel vil jeg gætte på, at den enten cykler sin cache, eller der er anden baggrundsvedligeholdelse af applikationsserverens processer.