Nápověda k odstraňování problémů SqlException:Časový limit vypršel při připojení, v situaci bez zatížení

Nedostatek paměti

Toto je velmi pravděpodobně problém s pamětí, možná zhoršený nebo vyvolaný jinými věcmi, ale stále je to neodmyslitelně problém s pamětí. existují dvě další (méně pravděpodobné) možnosti, které byste měli nejprve zkontrolovat a vyloučit (protože je to snadné):

Snadná kontrola možností:

1. Možná máte povoleno "Automatické zavírání":Automatické zavírání může mít přesně toto chování, ale je zřídkakdy zapnuté. Chcete-li to zkontrolovat, klikněte v SSMS pravým tlačítkem myši na databázi aplikace, vyberte „Vlastnosti“ a poté vyberte podokno „Možnosti“. Podívejte se na položku "Auto Close" a ujistěte se, že je nastavena na hodnotu False. Zkontrolujte také tempdb.

2. Může to být způsobeno úlohami SQL Agent:Zkontrolujte protokol historie agenta a zjistěte, zda se během událostí trvale spouštěly nějaké úlohy. Nezapomeňte také zkontrolovat úlohy údržby, protože věci jako Rebuilding Indexs jsou často uváděny jako problémy s výkonem, když běží. Tito jsou nyní nepravděpodobní kandidáti, jen proto, že by na ně normálně Profiler nebyl ovlivněn.

Proč to vypadá jako problém s pamětí:

Pokud nic neukazují, měli byste zkontrolovat problémy s pamětí. Předpokládám, že ve vašem případě je příčinou paměť, protože:

• Máte 1 GB paměti:I když je to technicky nad minimem pro SQL Server, je to mnohem méně, než je doporučeno pro SQL Server, a daleko pod tím, co je podle mých zkušeností přijatelné pro produkci, a to i pro málo zatížený server.

• Používáte IIS a SQL Server ve stejném boxu:Toto se nedoporučuje samo o sobě, z velké části kvůli sporu o paměť, který z toho plyne, ale s pouhým 1 GB paměti to má za následek IIS, aplikaci, SQL Server, OS a jakékoli další úkoly a/nebo údržba, to vše bojuje o velmi málo paměti. Systém Windows to zvládá tak, že přidělí paměť aktivním procesům tím, že ji agresivně odebere neaktivním procesům. Velkému procesu, jako je SQL Server, může trvat mnoho sekund nebo dokonce minut, než získá zpět dostatek paměti, aby byl v této situaci schopen kompletně obsloužit požadavek.

• Profiler odstranil 90 % problému:Toto je velká stopa, že problém je pravděpodobně v paměti, protože obvykle věci jako Profiler mají na tento konkrétní problém přesně tento účinek:úloha Profiler udržuje SQL Server jen trochu trochu aktivní po celou dobu. Často je to dostačující aktivita k tomu, abyste ji udrželi mimo seznam „scavengerů“ operačního systému, nebo alespoň poněkud snížili její dopad.

Jak zkontrolovat paměť jako viníka:

1. Vypnout Profiler:Má Heisenbergův vliv na problém, takže jej musíte vypnout, jinak nebudete schopni problém spolehlivě vidět.

2. Spusťte nástroj Sledování systému (perfmon.exe) z jiného boxu, který se vzdáleně připojuje ke službě sběru výkonu na boxu, na kterém běží váš SQL Server a IIS. nejsnáze to uděláte tak, že nejprve odeberete tři výchozí statistiky (jsou pouze místní) a poté přidejte potřebné statistiky (níže), ale nezapomeňte změnit název počítače v prvním rozevíracím seznamu, abyste se mohli připojit k vašemu SQL box.

3. Odešlete shromážděná data do souboru vytvořením "Protokolu čítače" na perfmon. Pokud s tím nejste obeznámeni, pak je pravděpodobně nejjednodušší shromáždit data do souboru odděleného tabulátory nebo čárkami, který můžete otevřít v Excelu a analyzovat.

4. Nastavte svůj perfmon pro shromažďování do souboru a přidejte do něj následující čítače:

   -- Processor\%Processor Time[Total]

   -- PhysicalDisk\% Idle Time[pro každý disk ]

   -- Fyzický disk\Průměr. Délka diskové fronty[pro každý disk ]

   -- Paměť\Stránky/s

   -- Paměť\Čtení stránky/s

   -- Paměť\Dostupné MB

   -- Síťové rozhraní\Bajty celkem/s[pro každé používané rozhraní ]

   -- Proces\% času procesoru[viz níže ]

   -- Proces\Chyby stránky/s[viz níže ]

   -- Proces\Working Set [viz níže ]

5. Pro čítače procesů (výše) chcete zahrnout proces sqlserver.exe, všechny procesy IIS a všechny stabilní aplikační procesy. Všimněte si, že to bude fungovat POUZE pro "stabilní" procesy. Procesy, které jsou podle potřeby neustále znovu vytvářeny, nelze tímto způsobem zachytit, protože neexistuje způsob, jak je specifikovat dříve, než existují.

6. Spusťte tuto kolekci do souboru v době, kdy k problému dochází nejčastěji. Nastavte interval sběru na něco blízkého 10-15 sekundám. (toto shromažďuje mnoho dat, ale toto rozlišení budete potřebovat k výběru samostatných událostí).

7. Jakmile máte jeden nebo více incidentů, zastavte shromažďování a poté otevřete soubor shromážděných dat v aplikaci Excel. Pravděpodobně budete muset přeformátovat sloupec časového razítka, aby byl užitečně viditelný a zobrazoval hodiny, minuty a sekundy. Pomocí svého protokolu IIS zjistěte přesný čas incidentů a poté se podívejte na data perfmon, abyste viděli, co se dělo před a po incidentu. Zejména chcete zjistit, zda jeho pracovní sada byla malá předtím a byla velká poté, se spoustou chybujících stránek mezi nimi. To je nejjasnější známka tohoto problému.

ŘEŠENÍ:

Buď oddělte IIS a SQL Server na dvě různá pole (upřednostňované), nebo do pole přidejte více paměti. Myslím, že 3-4 GB by mělo být minimum.

A co ten divný EF Stuff?

Problém je v tom, že je s největší pravděpodobností buď periferní, nebo pouze přispívá k vašemu hlavnímu problému. Pamatujte, že Profiler odstranil 90 % vašich incidentů, takže co zbývá, může být jiný problém, nebo to může být jen nejextrémnější přitěžovatel problému. Kvůli jeho chování bych tipoval, že buď cykluje mezipaměť, nebo probíhá nějaká jiná údržba procesů aplikačního serveru na pozadí.