Как устранить неполадки, связанные с ошибками тайм-аута SQL

Question

У нас было несколько экземпляров в день, когда мы получаем множество ошибок времени ожидания SQL от нескольких приложений (System.Data.SqlClient.SqlException: время ожидания истекло. Время ожидания истекло до завершения операции или сервера не отвечает.) В нашей сети более 100 различных приложений, как веб-, так и настольных. Все, от VB6 и Classic ASP до .NET 4. Я могу найти все виды данных, которые показывают побочные эффекты, но не могут точно определить причину этого. Наш администратор БД говорит, что с SQL-сервером все в порядке, а ИТ-специалисты говорят, что с веб-серверами или сетью все в порядке, поэтому, конечно, я остаюсь посередине, пытаясь устранить эту проблему.

Я просто ищу предложения о том, какие еще способы устранения неполадок я могу предпринять, чтобы попытаться отследить это.

Мы запускаем SQL Server 2008 R2 в кластере. К нему подключено несколько разных серверов, начиная от Windows Server 2003 до 2008 разных разновидностей.

Вот что я сделал до сих пор:

• Выполнение трассировки SQL для долго выполняющихся запросов и взаимоблокировок. Это не показывает взаимных блокировок во время проблем, и все долго выполняющиеся запросы совпадают с нашими ошибками тайм-аута, но выглядят как побочный эффект, не причина. Запросы, которые являются очень простыми и обычно возвращаются мгновенно, в конечном итоге занимают 30, 60 или 120 секунд. Это происходит в течение нескольких минут, после чего все начинает работать и прекрасно работает.
• Используйте системный монитор для отслеживания соединений пула соединений. Иногда это показывает некоторые всплески числа соединений, близкие к временам тайм-аутов, но все еще даже не на полпути к пределу 100 соединений по умолчанию. Опять же, здесь нет ничего, что могло бы указывать на причину.
• Разделение веб-приложений на разные пулы приложений. Мы пытались сузить приложения, которые, по нашему мнению, могут быть основной проблемой (наиболее болтливые и т. Д.), И поместить их в отдельные пулы приложений, но это не выглядит повлиять на что-либо или помочь нам сузить что-либо.
• Мониторинг использования диска на SQL Server. Мы провели некоторый мониторинг на SQL-сервере и не видим пиков или каких-либо признаков проблем при возникновении этих тайм-аутов.
• Проверено TempDB не является причиной проблемы.

Я вернусь и добавлю больше, если я подумаю о том, что еще мы попробовали. Пожалуйста, дайте мне знать о том, что делать дальше.

Answer 1

Мы столкнулись с этим в SQL Server 2012 / SP3, когда выполняли запрос через объект SqlCommand из приложения C #. Команда была простым вызовом хранимой процедуры, имеющей один параметр таблицы; мы передавали список из примерно 300 целых чисел. Процедура, в свою очередь, вызвала три пользовательские функции и передала таблицу в качестве параметра каждой из них. CommandTimeout был установлен на 90 секунд.

При запуске точно такого же хранимого процесса с тем же аргументом из SQL Server Management Studio запрос выполнялся через 15 секунд. Но при запуске его из нашего приложения с использованием вышеуказанной настройки время SqlCommand истекло. Одна и та же команда SqlCommand (с другими, но сопоставимыми данными) успешно работала в течение нескольких недель, но теперь она не работала с любым аргументом таблицы, содержащим более 20 или более целых чисел. Мы сделали трассировку и обнаружили, что при запуске из объекта SqlCommand база данных тратит все 90 секунд на получение блокировок и будет вызывать процедуру только примерно в момент времени ожидания. Мы изменили время CommandTimeout, и независимо от того, какое время мы выбрали, хранимый процесс будет вызываться только в самом конце этого периода. Таким образом, мы предполагаем, что SQL Server бесконечно многократно получал одни и те же блокировки и что только тайм-аут объекта Command заставлял SQL Server останавливать свой бесконечный цикл и начинать выполнение запроса, к тому времени было уже слишком поздно для успеха. Моделирование этого же процесса на аналогичном сервере с использованием аналогичных данных не показало такой проблемы. Нашим решением было перезагрузить весь сервер базы данных, после чего проблема исчезла.

Таким образом, похоже, что в SQL Server существует некоторая проблема, когда некоторый ресурс кумулятивно потребляется и никогда не освобождается. В конце концов, при подключении через SqlConnection и выполнении SqlCommand с параметром таблицы SQL Server входит в бесконечный цикл, получая блокировки. Цикл завершается тайм-аутом объекта SqlCommand. Решением является перезагрузка, по-видимому, восстановление (временное?) Исправность SQL Server.

Answer 2

Эти серверы виртуализированы?В другом посте я читал о том, что SQL-сервер иногда работает очень медленно из-за недостатка памяти.Это, в свою очередь, было вызвано так называемым всплывающим знаком памяти, который виртуализатор использовал для ограничения объема памяти, используемого этим виртуальным сервером.Это было трудно найти, потому что нагрузка на физическую память не имела никакого отношения к самому серверу SQL.

Другой распространенной причиной временного снижения производительности может быть вирусный сканер.При установке нового определения вируса все остальные процессы будут страдать и работать очень медленно.Проверьте любой другой процесс автоматического обновления, это может также потребовать много ресурсов довольно неожиданно.Удачи с этим!

Answer 3

Проблема заключается в том, что из-за неправильного запроса время выполнения запроса занимает более 60 секунд или блокировки таблицы.происходит;у нас есть запросы, которые блокируют запросы для своевременного выполнения.Время ожидания по умолчанию для запроса составляет 60 секунд, и после этого у нас будет SQLException для времени ожидания.

Пожалуйста, проверьте журналы SQL Server на наличие тупиков.Другой способ решить эту проблему - увеличить время ожидания для командного объекта (временное решение).

Answer 4

У меня была проблема, похожая на эту, и выяснилось, что это из-за настройки по умолчанию .NET Framework

Sqlcommand.Timeout

http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcommand.commandtimeout(v=VS.100).aspx

Значение по умолчанию составляет 30 секунд, как указано в приведенном выше URL-адресе Microsoft, попробуйте установить большее значение в секундах или, возможно, -1, прежде чем открывать соединение, чтобы посмотреть, решит ли это проблему.

Это может быть настройка в ваших файлах web.config или app.config или в ваших конфигурационных файлах приложения / веб-сервера.