Запросы SQL Server испытывают таймаут, поскольку TempGetStateItemExclusive становится названным непрерывно
Я выполняю сайт с достойным трафиком (~100 000 просмотров страницы в день), и эпизодически сайт был поставлен на колени из-за ошибок из-за тайм-аута SQL Server.
Когда я выполняю SQL Profiler, я вижу, что команда названа сотнями времен в секунду как это:
...
exec dbo.TempGetStateItemExclusive3 @id=N'ilooyuja4bnzodienj3idpni4ed2081b',...
...
Мы используем SQL Server для хранения состояния сеанса ASP.NET. Вышеупомянутое является хранимой процедурой, названной для захвата состояния сеанса для данной сессии. Это, кажется, цикличное выполнение, прося те же 2 или 3 сессии много раз.
Я нашел обещание, выглядящее текущими исправлениями, которые, кажется, обращаются к этой точной ситуации, но это, кажется, не решило проблему для нас. (Я предполагаю, что эти текущие исправления включены в новый пакет обновления.NET, потому что не похоже, что можно устанавливать его непосредственно больше). Я добавил, что ключ реестра вручную, но мы все еще видим вызовы хранимой процедуры цикличного выполнения как вышеупомянутый (запрос той же сессии намного чаще, чем каждые 500 мс)
Я не смог воссоздать это на машине разработки. Когда два запроса выполнены для того же идентификатора сессии, это, кажется, блокируется правильно, и даже пытается поразить SQL, пока первая страница не выпускает сессию.
Какие-либо идеи?Заранее спасибо!!!
3 ответа
Это может быть один из тех случаев, когда мне нужен был ответ на другой вопрос. Вопрос должен был быть "Почему я использую SQL для хранения информации о состоянии сессии". SQL гораздо медленнее и гораздо более отключен от веб-сервера, что, возможно, и способствовало возникновению этой проблемы. Я посмотрел размер нашей таблицы ASPStateTempSessions и понял, что он составляет всего около 1 Мб. Мы вернулись к
Следующим шагом, когда это диктует трафик, будет добавление других серверов и использование режима "StateServer", чтобы мы могли распределить использование памяти.
Я думаю, что изначально я сделал этот шаг, чтобы разобраться с бутылочным горлышком памяти, которое больше не является проблемой. (Это не лучшее решение проблемы с бутылочным горлышком памяти, к твоему сведению!)
ВАЖНОЕ ЗАМЕЧАНИЕ: Хорошо, так получается, что вся эта штука с "TempGetStateItemExclusive" не была проблемой, а просто симптомом другой проблемы. У нас было несколько запросов, которые вызывали проблемы с блокировкой, поэтому каждый SQL-запрос просто выгоняли. На самом деле, исправление было в том, чтобы идентифицировать и исправить проблемы с блокировкой. (Я все еще верю, что "InProc" - это то, что нужно) Эта ссылка очень помогла идентифицировать наши проблемы:
http://www.simple-talk.com/sql/sql-tools/how-to-identify-blocking-problems-with-sql-profiler/
Это было некоторое время, но это там Не задание очистки, которая проходит, чтобы удалить стральные сеансы? Это включено.
Это старый КБ упоминает его. Как я уже сказал, это было какое-то время.
просто из любопытства. Вы открыли, что Proce, чтобы увидеть, что это делает?
Если он просто делает оператор выбора, вы можете посмотреть, как он использует Nolock или нет. Если нет, добавьте нолока к нему и посмотрите, что произойдет.