Назад | Перейти на главную страницу

Хорошие инструменты и подходы для диагностики низкой производительности

Моя компания разрабатывает веб-приложение для просмотра данных, для нормальной работы которого требуется довольно приличная пропускная способность. Однако в последнее время мы многое меняем. Например, мы изменили нашу внутреннюю сетевую инфраструктуру, чтобы данные можно было размещать на отдельных машинах, подключенных через Gigabit Ethernet. Кроме того, само приложение продолжает выходить с новыми версиями, так как мы все еще находимся в стадии альфа- и бета-тестирования.

Недавно мы внесли некоторые изменения, которые снижают производительность, и мы хотим попытаться определить, в чем проблема, прежде чем мы начнем разбирать вещи. Это очень маленькая сеть, и у меня ограниченный опыт работы ИТ-администратором. У меня есть несколько идей, с чего начать, но я хотел бы сначала извлечь немного мудрости из опыта профессионалов: как решать / избегать подобных проблем? Какие наиболее полезные (Windows) инструменты вы использовали?

Я всегда придерживаюсь такого подхода: старайтесь тестировать что-то одно за раз.

Надежный «научный метод» действительно хорошо работает для устранения неполадок:

  1. Придумайте теорию, почему приложение работает медленно
  2. Придумайте тест, который подтвердит эту теорию.
  3. повторение.

Для веб-приложения это может означать:

  • может это быть база данных? Выполните несколько автономных SQL-запросов
  • может это быть веб-сервер? Протестируйте веб-сервер, загрузив статические страницы
  • это может быть приложение? Протестируйте веб-сервер, открыв динамические страницы, которые не попадают в базу данных
  • может это быть интерфейс приложений для БД? Протестируйте веб-сервер, открыв динамические страницы, которые попадают в базу данных.

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

Я все время вижу такие вещи:

резервное копирование на новом сервере занимает больше времени, чем на старом.

Но никто не проводил базовый тест диска, чтобы узнать, что у старого сервера было вдвое больше шпинделей, чем новый сервер ... или тест сети, чтобы выяснить, что новые серверы Gigabit Ethernet работают только на 100M.

При всем при этом, если это настраиваемое веб-приложение, у используемой вами инфраструктуры определенно есть способ сбрасывать информацию о производительности в файл журнала ... но это скорее вопрос для stackoverflow.

Сумма приведенных выше ответов составляет 90% того, что я бы сказал, вот остальные 10%:

  • Нужно извлечь урок об управлении окружающей средой, а точнее ее изменениями. Даже если вы уже измеряете производительность, изменение более чем одного элемента за раз означает, что любая проблема превращается в проблему, состоящую из двух этапов: поиска и следствия, и причины. Если вы меняете одну вещь за раз и имеете действующий план отката, любая проблема с производительностью обычно может быть связана с этим изменением (обычно иногда случаются странные вещи или кто-то меняет что-то, о чем вы не знаете) и, надеюсь, исправлена ​​путем отката вернуть изменение.
  • Лучше всего проводить измерения как можно раньше и чаще. Факты и точные данные облегчают решение проблем с производительностью.
  • Наименее полезная вещь, которую вы можете сделать, - это угадать, что не так, и изменить это без измерения. Вы будете удивлены, как часто разумно звучащее предположение не решает проблему или усугубляет ее.
  • Вы не можете измерить то, что еще не определили. Каждый раз, когда у вас возникают проблемы с производительностью, определите, каковы ожидания конечного пользователя, а затем найдите способ измерить успех или неудачу в достижении этого ожидания способом, который вы можете повторить. Сделайте это как можно более конкретно, и вы сузите объем того, что вам нужно исследовать, и тесты, которые вам нужно будет запустить для этого.
  • Что касается Windows, я большой поклонник журналов счетчиков производительности и использую PAL для их обработки и интерпретации. Отчет об обзоре системы и предлагаемые счетчики для этого отчета охватывают большинство возможных источников узких мест. http://pal.codeplex.com

Я подписался на метод устранения неполадок «Шерлок Холмс», также известный как метод устранения неполадок двоичного поиска:

  1. Разделите проблемное пространство пополам.
  2. Исключите половину проблемного места.
  3. Повторите с оставшимся проблемным пространством.

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

Этот метод совместим с научным методом и тестированием по одному.

Некоторые из лучших инструментов для устранения неполадок Windows взяты из Microsoft Sysinternals. И некоторые из лучших сведений о том, как их использовать (и техническую информацию о Windows в целом), можно найти на сайте Марка Руссиновича. блог и Интернет-трансляции. Его книга о Внутреннее устройство Windows также полон хорошей информации.

Учитывая вышесказанное, я бы предложил начать с программ Process Explorer и Process Monitor, чтобы взглянуть на любую запущенную веб-службу и посмотреть, что происходит. Обе программы позволяют отображать большой объем информации о запущенных процессах, которую можно настроить, щелкнув правой кнопкой мыши заголовки столбцов.

Что было изменено, что привело к проблемам с производительностью? Если бы только код был изменен, то я бы начал с него устранение неполадок.

Сравните статистику проблемы с известным хорошим состоянием и найдите расхождения.

Известное хорошее состояние может быть фактическим задокументированным состоянием. Он также может быть основан на стандарте ожидаемого поведения, таком как известное ожидаемое поведение сетевых протоколов или таких как практические правила о соответствующем среднем использовании ЦП.

Примеры:

Используя Wireshark или другой инструмент сетевого сниффера, вы постоянно видите повторяющиеся пакеты. Теперь вы можете попытаться понять, почему вы видите один и тот же IP-пакет на проводе. Возможно, у вас есть сценарий «локального маршрутизатора», или возможно, что-то фрагментирует IP-пакеты.

Средняя загрузка ЦП составляет 90%. Если среднее значение составляет 90%, то сервер, вероятно, часто загружает ЦП на максимум, что вызывает резервное копирование всего.

По рекомендации Джон Т, Мне нравится использовать dstat с gnuplot.