Высокий тип ожидания MSSEARCH в SQL Server 2005
На этой неделе я столкнулся с проблемой с типом ожидания MSSEARCH, и мне не удалось полностью диагностировать проблему.
Сервер работал без проблем в течение нескольких недель, пока на днях он внезапно не стал слишком долго отвечать на запросы пользователей.
Моя команда и я быстро обнаружили, что проблема находится в компоненте полнотекстового поиска, но мы понятия не имели, что ее вызывает. (FTS - это функция, активно используемая в нашей рабочей нагрузке, и до сих пор у нас не было проблем с ней.)
Мы попытались перезапустить службу MSFTE, но она не ответила.
Как показано на скриншоте выше, на сервере было чуть меньше 400 ожидающих задач (нормальная рабочая нагрузка менее 10) и они продолжали расти.
У меня не было слишком много времени, чтобы попытаться диагностировать его перед перезапуском нашего сервера, потому что он работал в производственной среде, поэтому у меня остались только журналы SQL Server и несколько дампов памяти MSFTE после полного перезапуска сервера.
Я ожидал, что смогу лучше понять проблему с ними, но мне не удалось получить из них много информации, поэтому я был бы очень рад, если бы кто-нибудь предложил указатель или пролил свет на это.
Все, что мы смогли сделать, это то, что служба полнотекстового поиска перестала работать, но я не нашел свидетельств такой ошибки в Интернете, и хотя сейчас она, похоже, работает нормально, я хотел бы действительно понять, что произошло. и предотвратить повторение этого.
Спасибо.
Нам не удалось полностью диагностировать проблему, но мы приняли меры, чтобы этого больше не повторилось, и я хотел бы задокументировать это здесь.
Во-первых, мы настроили полнотекстовую индексацию и заполнение полнотекстовых каталогов в периоды низкой активности системы, во время периодов обслуживания базы данных, и мы больше не оставляем систему автоматически заботиться об этом.
Во-вторых, теперь мы внимательно следим за службами полнотекстового поиска, их работой и объемом ресурсов, которые использует FTS. Мы задокументировали его использование и отслеживаем, среди прочего, размеры его файлов и операции ввода-вывода.
В-третьих, я установил несколько предупреждений, чтобы операторы (администраторы баз данных) получали уведомления, когда что-то пойдет не так (и неправильно вот относительно. В нашем случае, когда FTS начинает использовать больше ресурсов, чем предполагалось, плюс разумный порог.)
Пока этого не произошло снова (с тех пор, как это произошло в первый раз, прошел почти месяц), но в случае, если это произойдет, мы готовы действовать, желательно до того, как это коснется наших пользователей.
Прежде всего, это скриншот из SSMS 2008;)
Требования к ресурсам FTE сильно отличаются от обычных хранилищ базы данных; вам следует настроить удаленный захват Windows Perfcounter по крайней мере для следующих счетчиков:
- Загрузка процессора
- Физический диск I / O (чтения / записи в секунду) для каждого отдельного диска
- Очередь работы сервера
- Средняя длина дисковой очереди на диск
И несколько соответствующих счетчиков MSSQL, хотя вам понадобится работающий экземпляр MSSQL, чтобы иметь возможность настраивать их захват удаленно. Если у вас его нет, вам необходимо создать набор на сервере SQL и экспортировать / импортировать счетчики.
Собирайте эти данные примерно каждую минуту, и любые тенденции можно будет легко обнаружить.