Два дня назад на нашем производственном сервере произошло сильное замедление, основным признаком которого было то, что чрезвычайно большое количество запросов страдали от SQLTimeout. Я быстро опишу нашу настройку, то, что я исследовал, наш обходной путь, а затем задам свой вопрос.
Наша установка
Эта ветвь нашего приложения SAS находится на паре серверов. Один из них - это сервер приложений, на котором запущено несколько приложений на IIS, а другой, пострадавший от замедления, - это компьютер с Windows Server 2008, на котором работает SQL Server 2005. SQL размещает от 100 до 200 баз данных.
Проблема / расследование
Обслуживание практически прекращается. Некоторые запросы проходят, но большинство из них страдают тайм-аутом SQL. ЦП и ОЗУ машины SQL выглядят нормально, в среднем около 25% рабочей нагрузки ЦП и 85% ОЗУ. В то время я не думал проверять активность диска, так как сразу перешел к «EXEC sp_who2»
В результате были обнаружены сотни задач, заблокированных идентификатором 123, который был самим собой, а также сотни других, заблокированных идентификатором 456. При нормальном выполнении обычно блокирующие задачи отсутствуют. Когда я повторно запустил sp_who2 через 15-20 секунд, появлялись разные идентификаторы блокировки, но количество заблокированных / блокирующих задач, казалось, осталось прежним. (группы не учитывались из-за аварийного режима)
Большинство задач блокировались такими операторами, как «SELECT INTO» или «CREATE INDEX on temptable».
Обходной путь
Завершите процесс SQL и перезапустите его, чтобы восстановить службу. Замедление темпов роста не повторилось, но мы знаем, что находимся в опасности.
Мой вопрос
Что я могу сделать, чтобы решить эту проблему, желательно до того, как она возникнет снова?
Подвопросы:
Что я сделал до сих пор
Судя по симптомам, мы подозревали, что проблема связана с каким-то конфликтом в базе данных tempdb. (Другим симптомом было то, что щелчок правой кнопкой мыши по базе данных tempdb для просмотра свойств во время проблемы вызвал ошибку через короткое время)
Никакие журналы не указали, что на tempdb произошло событие автоматического увеличения, хотя, насколько мне известно, успехи автоматического увеличения не регистрируются, а только сбои.
С тех пор я прочитал много разных источников информации о конфликте с tempdb, в том числе:
http://www.sqlskills.com/blogs/paul/wait-statistics-or-please-tell-me-where-it-hurts/ http://www.sqlservercentral.com/blogs/robert_davis/2010/03/05/Breaking-Down-TempDB-Contention/
Насколько я понимаю, лучше всего иметь файлы tempdb с начальным размером и иметь по одному на ядро, до 8 файлов. Мы планируем реализовать это (8 ядер, 8 файлов) как можно скорее, поскольку это лучшая практика. Все они будут на одном жестком диске (пока), но мы считаем, что в худшем случае не будет улучшения, а в лучшем случае мы получим разницу между узким местом логической конкуренции и узким местом дискового ввода-вывода.
Однако мы не можем быть уверены в корреляции с возникшей у нас проблемой. Насколько я понимаю, разделение на несколько временных файлов поможет типу ожидания "PAGELATCH_XX", но при выполнении запроса Пола С. Рэндала (см. 1-ю опубликованную ссылку) во время нормальной активности этот тип ожидания отсутствует. Топ-3, которые я вижу при нормальной активности:
CXPACKET 68,63%
LATCH_EX 18,46%
PAGEIOLATCH_SH 4,35%
У меня нет возможности узнать, какой тип блокировки происходил во время замедления, поскольку тогда у нас не было всей этой информации.
Проблема в конечном итоге повторилась на следующий день после того, как я разместил этот вопрос.
Выполнив запрос Пола С. Рэндала, я быстро обнаружил, что происходит ряд ожиданий блокировки PAGELATCH_XX, поэтому с помощью sp_who2 я смог найти базы данных-виновников и перезапустить только соответствующие пулы клиентских приложений с веб-сервера в качестве гораздо менее жесткого обходного пути. восстановить сервис.
Мы также смогли проследить путь к реальным операциям, которые выполняют гораздо больше работы с tempdb, чем раньше, и постараемся исправить это, применив другой подход к этой проблеме.
Решение
Мы продвинулись вперед с разделение файла tempdb на несколько файлов в соответствии с рекомендациями, так как кажется, что это был правильный тип разногласий, чтобы это решение решило мою проблему.