У меня есть сайт IIS 6, работающий на Windows 2003 Server x86 с выпуском MS SQL2005 Enterprise с ASP Classic (без выбора). Сайт работает очень быстро, около 8000 просмотров страниц в час. Все мои таблицы SQL проиндексированы, и я использовал профилировщик для проверки своих запросов, самый медленный из которых составляет всего около 10-15 мс. У меня отключено автоматическое сжатие, автоматическое увеличение установлено на 250 МБ, база данных - 2 ГБ с 800 МБ свободного места.
Моя проблема в том, что время от времени сайт будет медленно сканировать без причины. Страницы, у которых есть простое «подключение к базе данных и увеличение счетчика посещений», работают нормально, но для более интенсивных страниц SQL, которые обычно выполняются примерно за 60 мс, требуется 25 000 мс для запуска. Это происходит примерно 30 секунд, а затем исчезает. У меня была проблема с потерянными наборами записей и подключениями из-за того, как я их выпускал. Я исправил это, и проблема стала намного лучше, но я все еще получаю их.
Есть ли способ с помощью permon и т. Д. Отслеживать, когда SQL Server или Windows закрывают эти сиротские подключения? По крайней мере, если я смогу отслеживать проблему, я буду знать, добиваюсь ли я прогресса или даже смотрю на правильные вещи. Что еще мне может не хватать?
Спасибо!
Мониторинг производительности действительно важен. Но даже при включенном мониторинге производительности у вас действительно должны быть базовые показатели производительности как из IIS, так и из SQL, включая ЦП, диск, сеть и оперативную память.
Perfmon можно использовать для сбора различных счетчиков для определения базовой производительности. Как только этот базовый уровень установлен, вы можете использовать его для выявления узких мест, пиков и неожиданных проблем.
Ваша база данных tempdb может расти. Возможно, запущено запланированное задание. Возможно, размер файла подкачки Windows был изменен. SQL может выгружать RAM на диск. Могут возникать узкие места запросов, обновлений, вставок и удалений.
Любая из этих вещей и многое другое может вызвать временные узкие места производительности, с которыми вы столкнулись.
Я бы очень рекомендовал пройти через эти статьи и руководства по настройке производительности sql от Брента Озара, замечательный SQL Guru / Master.
Еще один действительно удобный инструмент мониторинга sql - SQL-монитор by Red-Gate, который включает в себя множество ручных процессов, которые Brent проведет вас через простой в использовании устанавливаемый (хотя и не бесплатный) продукт.