Определение проблемы приложения, проблемы с базой данных или проблемы с оборудованием?

Question

У меня есть веб-приложение, поддерживаемое базой данных SQL Server, которое до вчерашнего дня работало нормально. Теперь у меня есть проблемы с производительностью с этим приложением. Как узнать, является ли это проблемой приложения, базы данных или аппаратного обеспечения?

Может ли кто-нибудь помочь мне пройти пошаговую процедуру базового устранения неполадок, чтобы выяснить, связана ли проблема производительности с приложением, базой данных или оборудованием?

Answer 1

Запустить Profiler. Фильтруйте по продолжительности, где значение> 50 мс, и вы, скорее всего, найдете худших нарушителей. Если это операторы SELECT, скопируйте их в анализатор запросов и запустите отображение фактического плана выполнения и настройте его соответствующим образом (создайте индексы и т. Д.).

Answer 2

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

Как только у вас появится этот список изменений, начните их резервировать по одному.

Пошаговая информация, эххх ... это сложно. Я всегда ищу что-то очевидное. Если я увижу что-то, что выглядит подозрительно, я перестану делать то, что я делаю, и продолжу расследование, или я помещу это на доску как возможную проблему.

1) Опять же, я всегда начинаю с создания списка всего, что изменилось с каждым элементом инфраструктуры (Брандмауэр, Коммутатор, БД, HotFix, Веб-сервер, ...) Если что-то изменилось, я всегда запрашиваю больше информации об этом изменении. Я полагаю, что у вас нет такой информации, а не потому, что я пытаюсь вас унизить, организациям требуется некоторое время, прежде чем они достигнут надлежащего уровня зрелости, когда их операции начинают регистрировать все изменения.

2) Начни смотреть логи. Поскольку все мои приложения находятся на Windows Server, я начинаю с просмотра журнала событий приложений. Я ищу ошибки приложения. Затем я иду в журнал системных событий, снова я ищу ошибки. Затем я могу выполнить анализ журналов IIS .... Обычно в этих журналах включено поле времени, поэтому я сосредотачиваюсь на долго выполняющихся запросах.

3) Далее я посмотрю на сервере БД. Я попрошу моего администратора баз данных запустить SQL Profiler, чтобы посмотреть, какие запросы занимают много времени. Я также попрошу их собрать информацию о блокировках базы данных. Я также прошу их проверить работоспособность БД (обновлены ли индексы, фрагментированы ли таблицы / индексы).

4) Далее у меня есть администраторы Windows Server, собирающие статистику счетчиков производительности на веб-сервере и SQL Server. Я хочу искать утечки памяти, очереди ввода-вывода, использование процессора.

Answer 3

Этот вопрос потребует дополнительных вопросов, прежде чем вы сможете приблизиться к диагностике проблемы:

У вас есть исходный код? Знаете ли вы, какие операторы SQL выполняются в то время, когда у приложения возникают проблемы с производительностью? Если это так, вы можете запустить операторы SQL для БД непосредственно из окна консоли SQL и посмотреть, не связана ли проблема с производительностью исключительно с БД.

Есть ли у вас доступ к журналам БД? Я не знаком с журналами SQL-серверов, но знаю, что в Oracle их много, и они полны хороших вещей.

Если предположить, что БД реагирует удовлетворительно, задействована ли сеть? Это веб-приложение? Есть ли у вас доступ к веб-журналам веб-сервера?

Проблема ограничена определенным набором пользователей? Некоторые пользователи испытывают проблему, а другие нет?

Answer 4

пользователь скажет: он работает медленно
босс скажет: исправь это
Сетевой парень скажет: это проблема с базой данных
парень базы данных скажет: это проблема приложения
Парень из приложения скажет: это проблема сети

Answer 5

Первый подозреваемый - это изменение в коде. Если что-то произошло в коде и проблема с производительностью коррелирует с этим, то это главный подозреваемый.

Если ничего не изменилось, то база данных является хорошим подозреваемым. Предполагая, что из вашего тега вы используете MS-SQL, есть два вероятных сценария:

1. Данные достигли определенного уровня, когда механизм изменил алгоритм, используемый для выполнения запросов, и этот новый алгоритм требует другой индексации.

2. Индексы просто необходимо перестроить. Восстановление индексов довольно тривиально, как видно из этой ссылки .