Помощ за отстраняване на неизправности SqlException:Времето за изчакване е изтекло при свързване, в ситуация на незареждане

Няма достатъчно памет

Много вероятно това е проблем с паметта, може би утежнен или предизвикан от други неща, но все още по своята същност проблем с паметта. има две други (по-малко вероятни) възможности, които първо трябва да проверите и елиминирате (защото е лесно да го направите):

Лесни за проверка възможности:

1. Може да сте активирали „Автоматично затваряне“:Автоматичното затваряне може да има точно това поведение, но рядко се включва. За да проверите това, в SSMS щракнете с десния бутон върху базата данни на вашето приложение, изберете „Свойства“ и след това изберете панела „Опции“. Погледнете записа „Автоматично затваряне“ и се уверете, че е зададен на False. Проверете и tempdb.

2. Задачи на SQL Agent може да го причиняват:Проверете регистрационния файл на хронологията на агента, за да видите дали има някакви задания, изпълнявани постоянно по време на събитията. Не забравяйте да проверите и заданията за поддръжка, тъй като неща като възстановяване на индекси често се цитират като проблеми с производителността, докато се изпълняват. Сега това са малко вероятни кандидати, само защото обикновено не биха били засегнати от Profiler.

Защо изглежда като проблем с паметта:

Ако те не показват нищо, тогава трябва да проверите за проблеми с паметта. Подозирам, че паметта е причината във вашия случай, защото:

• Имате 1 GB памет:въпреки че технически това е над минимума за SQL Server, то е много под препоръчителното за SQL Server и много под това, което според моя опит е приемливо за производство, дори за слабо натоварен сървър.

• Изпълнявате IIS и SQL Server на една и съща кутия:Това не се препоръчва само по себе си, до голяма степен поради конкуренцията за памет, която произтича, но само с 1 GB памет води до IIS, приложението, SQL Server, ОС и всякакви други задачи и/или поддръжка, всички се борят за много малко памет. Начинът, по който Windows управлява това, е да даде памет на активните процеси, като я отнема агресивно от неактивните процеси. Може да отнеме много секунди или дори минути на голям процес като SQL Server, за да си върне достатъчно памет, за да може напълно да обслужи заявка в тази ситуация.

• Profiler направи 90% от проблема да изчезне:Това е голяма индикация, че паметта вероятно е проблемът, защото обикновено неща като Profiler имат точно този ефект върху този конкретен проблем:задачата Profiler поддържа SQL Server само малко малко активен през цялото време. Често това е достатъчно активност или да я държи извън списъка на операционната система за „почистване“ или поне да намали донякъде нейното въздействие.

Как да проверите за памет като виновник:

1. Изключете Profiler:Той има ефект на Хайзенберг върху проблема, така че трябва да го изключите или няма да можете да видите надеждно проблема.

2. Стартирайте системен монитор (perfmon.exe) от друга кутия, която отдалечено се свързва с услугата за събиране на производителност на кутията, на която работят вашият SQL Server и IIS. можете най-лесно да направите това, като първо премахнете трите статистики по подразбиране (те са само локални) и след това добавите необходимите статистики (по-долу), но не забравяйте да промените името на компютъра в първото падащо меню, за да се свържете с вашия SQL кутия.

3. Изпратете събраните данни във файл, като създадете „Counter Log“ на perfmon. Ако не сте запознати с това, тогава най-лесното нещо, което можете да направите, вероятно е да съберете данните в табулатор или разделен със запетая файл, който можете да отворите с Excel за анализ.

4. Настройте вашия perfmon да събира във файл и добавете следните броячи към него:

   -- Процесор\%Процесорно време[Общо]

   -- PhysicalDisk\% време на неактивност[за всеки диск ]

   -- PhysicalDisk\Avg. Дължина на опашката на диска[за всеки диск ]

   -- Памет\Страници/сек

   -- Памет\Четене на страница/сек

   -- Памет\Налични MBytes

   -- Мрежов интерфейс\Общо байтове/сек[за всеки използван интерфейс ]

   -- Процес\% процесорно време[вижте по-долу ]

   -- Process\Page Faults/sec [вижте по-долу ]

   -- Process\Working Set [вижте по-долу ]

5. За броячите на процеси (по-горе) искате да включите процеса sqlserver.exe, всички IIS процеси и всички процеси на стабилно приложение. Имайте предвид, че това ще работи САМО за "стабилни" процеси. Процеси, които непрекъснато се пресъздават при необходимост, не могат да бъдат уловени по този начин, защото няма начин да бъдат посочени, преди да съществуват.

6. Стартирайте тази колекция във файл през времето, когато проблемът се случва най-често. Задайте интервала на събиране на около 10-15 секунди. (това събира много данни, но ще ви трябва тази резолюция, за да изберете отделните събития).

7. След като имате един или повече инциденти, спрете събирането и след това отворете файла със събрани данни с Excel. Вероятно ще трябва да преформатирате колоната с клеймо за време, за да бъде полезно видима и да показва часове, минути и секунди. Използвайте вашия IIS регистрационен файл, за да намерите точното време на инцидентите, след което погледнете данните за perfmon, за да видите какво се е случвало преди и след инцидента. По-специално искате да видите дали неговият работен набор е бил малък преди и е бил голям след това, с много грешки между страниците. Това е най-ясният знак за този проблем.

РЕШЕНИЯ:

Или отделете IIS и SQL Server в две различни кутии (за предпочитане), или добавете повече памет към кутията. Мисля, че 3-4 GB трябва да са минимум.

Какво ще кажете за тези странни EF неща?

Проблемът тук е, че най-вероятно е или периферен, или само допринася за основния ви проблем. Не забравяйте, че Profiler направи така, че 90% от вашите инциденти да изчезнат, така че това, което остава, може да е различен проблем или може да е само най-крайният влошаващ фактор на проблема. Поради поведението му бих предположил, че той или циклизира кеша си, или има някаква друга поддръжка на фона на процесите на сървъра на приложения.