Hulp bij het oplossen van problemen met SqlException:time-out is verlopen bij verbinding, in een niet-belaste situatie

Onvoldoende geheugen

Dit is zeer waarschijnlijk een geheugenprobleem, misschien verergerd of veroorzaakt door andere dingen, maar nog steeds inherent een geheugenprobleem. er zijn twee andere (minder waarschijnlijke) mogelijkheden die u eerst moet controleren en elimineren (omdat dit gemakkelijk te doen is):

Eenvoudig te controleren mogelijkheden:

1. Mogelijk hebt u "Automatisch sluiten" ingeschakeld:Automatisch sluiten kan precies dit gedrag vertonen, maar het is zeldzaam dat het wordt ingeschakeld. Om dit te controleren, klikt u in SSMS met de rechtermuisknop op uw toepassingsdatabase, selecteert u "Eigenschappen" en selecteert u vervolgens het paneel "Opties". Kijk naar het item "Automatisch sluiten" en zorg ervoor dat het is ingesteld op False. Controleer ook tempdb.

2. Mogelijk worden dit veroorzaakt door SQL Agent-taken:Controleer het geschiedenislogboek van de agent om te zien of er tijdens de gebeurtenissen consistent taken werden uitgevoerd. Vergeet niet om ook onderhoudstaken te controleren, aangezien zaken als het opnieuw opbouwen van indexen vaak worden genoemd als prestatieproblemen terwijl ze worden uitgevoerd. Dit zijn nu onwaarschijnlijke kandidaten, alleen omdat ze normaal gesproken niet worden beïnvloed door de Profiler.

Waarom het op een geheugenprobleem lijkt:

Als die niets laten zien, moet u controleren op geheugenproblemen. Ik vermoed dat geheugen in uw geval de oorzaak is, omdat:

• Je hebt 1 GB geheugen:hoewel dit technisch boven het minimum voor SQL Server ligt, is het ver onder de aanbevolen waarde voor SQL Server en ver onder wat in mijn ervaring acceptabel is voor productie, zelfs voor een licht belaste server.

• U gebruikt IIS en SQL Server op dezelfde box:dit wordt op zichzelf niet aanbevolen, grotendeels vanwege de strijd om geheugen die daaruit voortvloeit, maar met slechts 1 GB geheugen resulteert dit in IIS, de app, SQL Server, de OS en alle andere taken en/of onderhoud vechten allemaal om heel weinig geheugen. De manier waarop Windows dit beheert, is om geheugen te geven aan de actieve processen door het agressief weg te nemen van de niet-actieve processen. Het kan vele seconden of zelfs minuten duren voordat een groot proces zoals SQL Server genoeg geheugen terugkrijgt om in deze situatie een verzoek volledig te kunnen verwerken.

• Profiler zorgde ervoor dat 90% van het probleem verdween:dit is een grote aanwijzing dat geheugen waarschijnlijk het probleem is, omdat dingen als Profiler meestal precies dit effect hebben op dit specifieke probleem:de Profiler-taak houdt de SQL Server slechts een beetje beetje actief de hele tijd. Vaak is dit net genoeg activiteit om het van de "scavenger"-lijst van het besturingssysteem te houden, of op zijn minst de impact enigszins te verminderen.

Hoe te controleren op geheugen als de boosdoener:

1. Zet de profiler uit:het heeft een Heisenberg-effect op het probleem, dus u moet het uitschakelen, anders kunt u het probleem niet betrouwbaar zien.

2. Voer een systeemmonitor (perfmon.exe) uit vanuit een andere box, die op afstand verbinding maakt met de prestatieverzamelservice op de box waarop uw SQL Server en IIS draaien. u kunt dit het gemakkelijkst doen door eerst de drie standaardstatistieken te verwijderen (ze zijn alleen lokaal) en vervolgens de benodigde statistieken toe te voegen (hieronder), maar zorg ervoor dat u de computernaam in de eerste vervolgkeuzelijst wijzigt om verbinding te maken met uw SQL doos.

3. Stuur de verzamelde gegevens naar een bestand door een "tellerlogboek" op perfmon aan te maken. Als u hier niet bekend mee bent, is het waarschijnlijk het gemakkelijkst om de gegevens te verzamelen in een door tabs of komma's gescheiden bestand dat u met Excel kunt openen om te analyseren.

4. Stel uw perfmon in om te verzamelen in een bestand en voeg de volgende tellers toe:

   -- Processor\% Processortijd [Totaal]

   -- PhysicalDisk\% Idle Time[voor elke schijf ]

   -- Fysieke schijf\Gem. Lengte schijfwachtrij[voor elke schijf ]

   -- Geheugen\Pagina's/sec

   -- Geheugen\Paginalezingen/sec

   -- Geheugen\Beschikbare MBytes

   -- Netwerkinterface\Bytes Totaal/sec[voor elke gebruikte interface ]

   -- Proces\% processortijd[zie hieronder ]

   -- Process\Page Faults/sec[zie hieronder ]

   -- Process\Working Set [zie hieronder ]

5. Voor de procestellers (hierboven) wilt u het sqlserver.exe-proces, alle IIS-processen en alle stabiele toepassingsprocessen opnemen. Merk op dat dit ALLEEN werkt voor "stabiele" processen. Processen die voortdurend opnieuw worden gemaakt als dat nodig is, kunnen niet op deze manier worden vastgelegd omdat er geen manier is om ze te specificeren voordat ze bestaan.

6. Voer deze verzameling uit naar een bestand gedurende de tijd dat het probleem zich het vaakst voordoet. Stel het verzamelinterval in op iets in de buurt van 10-15 seconden. (dit verzamelt veel gegevens, maar je hebt deze resolutie nodig om de afzonderlijke gebeurtenissen te selecteren).

7. Nadat u een of meerdere incidenten heeft gehad, stopt u met het verzamelen en opent u vervolgens uw verzamelde gegevensbestand met Excel. U zult waarschijnlijk de tijdstempelkolom opnieuw moeten formatteren om nuttig zichtbaar te zijn en uren, minuten en seconden weer te geven. Gebruik uw IIS-logboek om het exacte tijdstip van de incidenten te vinden en bekijk vervolgens de prestatiegegevens om te zien wat er voor en na het incident gebeurde. In het bijzonder wil je zien of de werkset eerst klein was en daarna groot, met veel paginafouten ertussen. Dat is het duidelijkste teken van dit probleem.

OPLOSSINGEN:

Scheid IIS en SQL Server op twee verschillende boxen (bij voorkeur) of voeg meer geheugen toe aan de box. Ik zou denken dat 3-4 GB een minimum zou moeten zijn.

Hoe zit het met dat rare EF-gedoe?

Het probleem hier is dat het hoogstwaarschijnlijk perifeer is of alleen bijdraagt ​​​​aan uw hoofdprobleem. Onthoud dat Profiler ervoor heeft gezorgd dat 90% van uw incidenten is verdwenen, dus wat overblijft, misschien een ander probleem zijn, of het kan alleen de meest extreme verergering zijn van het probleem. Vanwege zijn gedrag vermoed ik dat het ofwel zijn cache aan het ronddraaien is of dat er een ander achtergrondonderhoud is van de applicatieserverprocessen.