Тайм-аут SqlException истек, но не достигнут

Время от времени наш сервер выдает это хорошо известное исключение:

Истекло время ожидания. Время ожидания истекло до завершения операции или сервер не отвечает.

Это происходит под давлением, когда сервер обрабатывает большие запросы. Я провел небольшое исследование и обнаружил, что могу изменить настройку тайм-аута соединения в строке подключения и / или свойства считывателя данных SqlCommand.Timeout.

По умолчанию для тайм-аута команды sql установлено значение 30 секунд, а для тайм-аута соединения - 15, и мы никогда их не отменяем.

Я воспроизвел контекст и вручную выполнил все запросы в студии управления. Их продолжительность составляет около 1 секунды и всегда намного больше 30.

Но, как ни странно, когда я смотрю журналы сервера, это исключение сразу же выдается при вызове запроса. Я имею в виду, что запрос выполняется, и через одну миллисекунду возникает исключение. Извините, но позвольте мне по-своему взглянуть на эту 8-o.

Для полноты, наш экземпляр sql зеркалируется с другим в синхронном режиме. Мы используем Ado.Net через настольные адаптеры.


sql-server timeout ado.net mirroring
person Roubachof    schedule 21.04.2011    source источник

Ответы (3)


arrow_upward
3
arrow_downward

Фактически, мы все еще испытывали эти случайные таймауты даже после установки READ_COMMITED_SNAPSHOT.

Установка зеркала в асинхронном режиме не помогла, запросы, выполняемые в нескольких потоках, по-прежнему случайным образом отсрочиваются примерно через 1 мс, всегда в периоды занятости. С другой стороны, конкретный запрос, вызвавший тайм-аут (оператор INSERT), выполнялся очень быстро (менее 1 мс ЦП и в среднем около 10 операций чтения).

Стек вызовов был следующим:

в System.Data.ProviderBase.DbConnectionPool.GetConnection (DbConnection owningObject)

в System.Data.ProviderBase.DbConnectionFactory.GetConnection (DbConnection owningConnection)

в System.Data.ProviderBase.DbConnectionClosed.OpenConnection (DbConnection outerConnection, DbConnectionFactory connectionFactory)

в System.Data.SqlClient.SqlConnection.Open ()

Таким образом, время ожидания не было связано с самим запросом.

Согласно этому другому сообщению: Тайм-ауты одновременного подключения SQL в многопоточном Windows Сервис и связанный сообщение в блоге MSDN, в котором говорится об ошибке ADO.NET, мы попытались установить тайм-аут подключения на 150 в строке подключения.

Не могу быть уверенным, что мы столкнулись с этой ошибкой, но с момента этого изменения больше не было тайм-аутов.

person Whaaag    schedule 24.11.2011

arrow_upward
2
arrow_downward

В конце концов, после нескольких часов отслеживания и профилирования проблема заключалась в соотношении двух вещей:

  1. Чтение зафиксированного уровня изоляции Sql Server по умолчанию, приводящего к блокирующим ситуациям
  2. Некоторые действительно плохо настроенные запросы и хранимые процедуры смешиваются с безиндексными таблицами

Первая причина была устранена с помощью

ALTER DATABASE <dbName> SET READ_COMMITTED_SNAPSHOT ON

Второй - с четкой перезаписью запросов и индексацией таблиц.

person Roubachof    schedule 06.05.2011

arrow_upward
0
arrow_downward

На этом этапе я бы запустил SQL Profiler и посмотрел, какие запросы выполняются.

person William Xifaras    schedule 21.04.2011
comment
Я уже сделал это, воспроизвел контекст и выполнил неудавшиеся запросы вручную в студии управления. Дело в том, что выполнение запроса, похоже, не превышает тайм-аут по умолчанию, но «исключение тайм-аута» все равно отправляется. - person Roubachof; 21.04.2011
comment
Взгляните на эту информацию в MSDN - если вы еще этого не сделали. msdn.microsoft.com/en-us/library/ms190181.aspx - person William Xifaras; 22.04.2011
comment
Извините, я ничем не могу больше помочь. - person William Xifaras; 22.04.2011