SQL Server запрашивает тайм-аут, так как TempGetStateItemExclusive постоянно вызывается - PullRequest
4 голосов
/ 28 января 2010

Я управляю сайтом с приличным трафиком (~ 100 000 просмотров страниц в день), и время от времени сайт останавливается из-за ошибок времени ожидания SQL Server.

Когда я запускаю SQL Profiler, я вижу команду, вызываемую сотни раз в секунду, например:

...
exec dbo.TempGetStateItemExclusive3 @id=N'ilooyuja4bnzodienj3idpni4ed2081b',...
...

Мы используем SQL Server для хранения состояния сеанса ASP.NET. Выше приведена хранимая процедура, вызываемая для получения состояния сеанса для данного сеанса. Кажется, он зацикливается, снова и снова прося один и тот же 2 или 3 сеанса.

Я нашел перспективное исправление , которое, похоже, решает эту точную ситуацию, но, похоже, не решило проблему для нас. (Я предполагаю, что это исправление включено в самый последний пакет обновления .NET, поскольку похоже, что вы больше не можете устанавливать его напрямую). Я добавил этот раздел реестра вручную, но мы по-прежнему видим циклические вызовы хранимых процедур, как указано выше (запрос одного и того же сеанса гораздо чаще, чем каждые 500 мс)

Мне не удалось воссоздать это на компьютере разработчика. Когда два запроса выполняются для одного и того же идентификатора сеанса, кажется, что он корректно блокируется и даже пытается нажать SQL, пока первая страница не освободит сеанс.

Есть идеи? Заранее спасибо !!!

Ответы [ 3 ]

2 голосов
/ 05 февраля 2010

Это может быть один из тех случаев, когда мне нужен был ответ на другой вопрос. Вопрос должен был быть «Почему я использую SQL для хранения информации о состоянии сеанса?» SQL намного медленнее и гораздо больше отсоединяется от веб-сервера, что может способствовать возникновению этой проблемы. Я посмотрел размер нашей таблицы ASPStateTempSessions и понял, что она составляет всего около 1 МБ. Мы вернулись к <sessionState mode="InProc" ... />, и проблема исправлена ​​(и сайт работает быстрее)

Следующим шагом, когда диктует трафик, будет добавление других серверов и использование режима «StateServer», чтобы мы могли распределить использование памяти.

Я думаю, что изначально сделал этот шаг, чтобы справиться с горлышком бутылки памяти, который больше не является проблемой. (Это не очень хорошее решение для борьбы с горлышком бутылки памяти, к вашему сведению!)

ВАЖНОЕ РЕДАКТИРОВАНИЕ: Хорошо, получается, что вся вещь «TempGetStateItemExclusive» не была проблемой, она была просто симптомом другой проблемы. У нас было несколько запросов, которые вызывали проблемы с блокировкой, поэтому каждый SQL-запрос просто отбрасывался. Фактическим решением было выявить и устранить проблемы с блокировкой. (Я все еще верю, что «InProc» - это то, что нужно). Эта ссылка очень помогла выявить наши проблемы:

http://www.simple -talk.com / SQL / SQL-инструменты / как к идентификации блокирующий-проблемы-с-SQL-профайлер /

0 голосов
/ 28 января 2010

Просто из любопытства. Вы открыли этот процесс, чтобы посмотреть, что он делает?

Если это просто оператор выбора, вы можете посмотреть, использует ли он NOLOCK или нет. Если нет, добавьте к нему NOLOCK и посмотрите, что произойдет.

0 голосов
/ 28 января 2010

Прошло какое-то время, но не там ли работа по очистке, которая запускает удаление устаревших сессий? Это включено.

Этот старый KB упоминает об этом. Как я уже сказал, это было давно.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...