У нас около 200 настольных компьютеров в США, которые ежедневно используют наши точки продаж / веб-приложения. Это приложение считается критически важным и не может выйти из строя для наших розничных продавцов.
В течение последних нескольких месяцев пользователи испытывали серьезные замедления работы приложений и сбои. Процедуры, которые должны занимать 1-2 секунды, теперь занимают 10-20 секунд.
Последний раз они начинались незадолго до пика в цветочном бизнесе (как раз перед Рождеством), а теперь и снова (как раз перед Днем Святого Валентина). Мы видим одну общую закономерность: чем больше нагрузка, тем больше система тормозит и дает сбой. После Рождества мы добавили больше памяти и дисков, чтобы посмотреть, поможет ли это стабилизировать систему.
Внешний администратор БД и старший программист .net были привлечены для анализа и определения основной причины этих проблем. Мы рассмотрели как аппаратную, так и программную и сетевую стороны. Администратор DBA потратил много часов на анализ базы данных и сделал некоторые настройки и модификации за последние несколько недель.
Предварительно установлено, что определенные хранимые процедуры или отчеты в приложении были плохо написаны и потребляли много ресурсов (или в некоторых случаях создавали бесконечные циклы). Некоторые процедуры были отключены. Администратор БД работает с программистом над оптимизацией этих процедур в настоящее время и исправлением ошибок.
Нам не удавалось постоянно воспроизводить сбои или замедления самостоятельно.
Наша текущая настройка выглядит следующим образом: База данных asp 2.0 - Dell 2950 - SQL Server 2005 20 Гб (8 x 73 Гбайт) Размер веб-сервера около 20 Гбайт - Dell 1950 - 8 Гбайт Windows 2003 R2 Enterprise SP2 (4 x 73 Гбайт) iis6 (использование памяти около 50 % при текущих 4 пулах приложений).
Буду признателен за любые комментарии, прежде чем я выдерну все оставшиеся волосы ...
Когда с нами начинают происходить странные вещи, мы настраиваем DebugDiag1.2 для обнаружения и регистрации сбоев, а также отслеживание неудачных запросов с трассировкой страниц .net, чтобы точно определить, что делают плохие запросы.
DebugDiag: скачать
Некоторые инструкции Вот. Я бы установил его с «типом действия для ненастроенных исключений первого шанса» как «трассировка стека журнала», если вы действительно не умеете просматривать дампы.
Отслеживание неудачных запросов: настройка Вот.
С вашим собственным следы страницы:
Ничего конкретного предложить не могу, особенно если над этим уже работали сторонние специалисты. Если это началось только в последние несколько месяцев, попробуйте найти, что изменилось, или проверьте свое оборудование.
Есть обновления Windows? антивирусные программы сменили или запустить проверку по расписанию в течение дня? резервные задания? диск почти заполнен? пакет обновления sql server установлен? вы ведь проверили журналы событий?
Также проверьте сетевые кабели и карты. Есть сетевые ошибки? Неисправный кабель, сетевая карта или коммутатор могут выглядеть нормально, если судить по индикаторам, но могут быть неисправными, работать в полудуплексном режиме, сбрасывать пакеты и т. Д.
Вы вносили какие-либо изменения в программное обеспечение? сломать или уронить какие-то индексы?
Если ваша версия SQL Server включает профилировщик, настройте его для записи медленных запросов.
Или добавьте некоторые инструменты мониторинга, такие как nagios, которые отправляют вам электронное письмо, как только нагрузка на процессор начинает расти. Тогда вы можете сразу войти в ящик и начать расследование.