Стратегии анализа производительности

Question

Я назначена задаче устранения неполадок при настройке производительности.

Сценарий: среда с несколькими приложениями, работающая на нескольких сетевых компьютерах, использующих базы данных. ОС - Unix, DB - Oracle. Бизнес-логика реализована в приложениях с использованием синхронной/асинхронной связи. Приложения являются многопользовательскими пользователями с несколькими сотнями пользователей центров обработки вызовов в пиковое время. Пользовательские интерфейсы основаны на веб-интерфейсах.

Приложения сторонние, я могу получить доступ к разработчикам и исходному коду. У меня есть только производственная система и функциональная тестовая среда, без среды тестирования нагрузки.

Проблема: плохая производительность! Мне нужны быстрые результаты. Менеджмент сходит с ума.

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

Какова будет ваша стратегия поиска коренных причин?

Answer 1

Если это 11-часовой сценарий типа, и это система, в которой вы идете без каких-либо предварительных знаний, вот как я буду заниматься этим - конкретные инструкции ниже приведены для unix newb, но общие принципы звучат для любой системной сортировки:

1. Создайте текстовый файл с именем каждого из ваших производственных хостов в нем. Назовем это prodhosts
2. Получите ваш открытый ключ ssh на ~/.ssh/authorized_keys на каждом из prod_hosts. Если вы не знакомы с агентами ssh и как быстро входить в систему, заходите на 10 минут и читайте на нем, или используйте script that handles it for you.

3. Проверьте систему нагрузки на всех серверах

   for i in `cat prodhosts` ; do echo $i ; ssh $i uptime ; done 
   

   средние Высокие нагрузки (очень вообще говоря, больше, чем количество ядер у вас есть) указывают на проблемные серверы. Запишите их - вы скоро посмотрите на них.

4. Проверьте наличие полных дисков - это очень распространены

   for i in `cat prodhosts` ; do echo $i ; ssh $i df -h ; done 
   

   Любой хозяин, это на уровне или около 100% использование диска будет проблемой. Запишите все проблемные серверы, которые вы найдете таким образом.

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

   for i in `cat prodhosts` ; do echo $i ; ssh $i free -m ; done 
   

   Это скажет вам, сколько памяти у вас есть, и сколько их подкачки. Вот что здоровая система с около 16 Гб оперативной памяти может выглядеть следующим образом:

      total  used  free  shared buffers  cached 
   Mem:   15884  15766  117   0   61  14928 
   -/+ buffers/cache:  776  15107 
   Swap:  31743   0  31743 
   

   Вполне вероятно, что ваша проблема коробка будет иметь большое количество в used колонки Swap. Это объем памяти, которую ваши приложения пытаются использовать, что ваша машина не имеет.

6. Вооружившись этой информацией, вы должны иметь лучшее представление о том, где узкое место находится в 95% всех систем (оставшиеся 5% будут замедлены удаленными сетевыми ресурсами или гремлинами). Теперь вы делаете стандартную сортировку. Начните в нижней части стека - то есть, если у вас высокая загрузка и дрянная работоспособность во всем мире, начните с вашей базы данных, потому что вполне вероятно, что ее проблемы каскадируются повсюду (если ваша БД жужжит хорошо, очевидно, посмотрите в другом месте в первую очередь, но всегда с подозрением относиться к базам данных, когда производительность находится на линии):

   • Database - получить журнал всех запросов выполняющиеся, что взять на себя, скажем, 400мс, как большой из периода выборки, как вы можете позволить себе взять (в идеале эти журналы уже существуют, в противном случае они собираются вместе и позволяют собирать данные в течение часа или около того). Взломайте несколько скриптов, которые нормализуют запросы и выясняют, какие запросы занимают самое большее всего времени в вашей системе (также смотрите на поиски жалких 1-разовых запросов, которые слишком медленны и замедляют все остальное). Вы захотите проанализировать эти запросы с помощью плана объяснения и выяснить, как их лучше ударить по индексам или выяснить, как их вообще удалить из своей системы. Обратитесь к вашему администратору баз данных за помощью, если он у вас есть, и используйте, если можете, готовый анализатор журнала запросов.
   • Приложение - просмотрите журналы и следите за чем-то сумасшедшим. Приложения и протоколирование сильно различаются, поэтому это зависит от системы.
   • Операционная система (используйте это на любой коробке) - посмотрите на вывод dmesg на свой ящик - есть ли у него какие-либо предупреждения? Просмотрите журналы в/var/log - посмотрите что-нибудь интересное? Кажется, что ломаются журналы? Это ваши проблемы.

После того, как вы сделали быстрое и свободное хакерство, чтобы вернуть систему в стабильное состояние, сесть и поговорить с «управлением» о мониторинге, анализ журналов, и все стандартных инструментов торговля sysadmin, которая должна помочь предотвратить появление сценариев, подобных тем, с которыми вы сталкиваетесь.Читайте на Nagios, Munin, rsyslog и т. Д. И т. Д., Или нанимайте тех, кто может автоматизировать ваш центр обработки данных и его мониторинг для вас. Кроме того, если третье лицо приложения, поговорите с ними о том, как они ожидают, что вы справитесь с такой ситуацией - если это готовый продукт, у них должны быть рекомендации по требованиям, необходимым для успешного запуска своего приложения. Если это то, что вы наняли произвольной подрядной компанией для создания, подумайте над рекомендациями руководству, что они нанимают людей, которые знают, что они делают.

Answer 2

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

Проверьте, какой компонент простаивает, может быть какой-то тайм-аут или недостающие ресурсы.

Все, что угодно зависит от архитектуры приложения. Вам определенно нужна тестовая среда для установки достойного теста, альтернативно пусть менеджеры (которые купили этот материал) платят за стороннюю поддержку.

Answer 3

Запустите монитор файлов sysinternals и монитор процесса, чтобы найти чрезмерный ввод-вывод. Наиболее легко сделать, когда peformance затягивает, когда они запускают определенные отчеты или программы. Партнерство с вашим DBA Oracle для мониторинга производительности базы данных. Поделитесь с sysadmin, чтобы отслеживать диски, на которых находятся таблицы Oracle. Вы ищете плохо выполненные запросы, что приводит к полному сканированию таблицы, результатам матрицы и т. Д. Имеет системную насыщенность sysadmin/netadmin.

Скопируйте производственные данные и код в другую, изолируйте тестовую систему и измерьте производительность. Смотрите, где производительность процессора и диска проходит через крышу.

Обратите внимание, что выход FileMonitor является .csv-форматом и быстро перегружает Excel. Но Excel может рассматривать этот .csv как внешний источник данных, и вы можете подключить его к сводной таблице. Просто используйте мастер Pivot Table, укажите файл отчета (.txt) и измерьте имя приложения, имя файла набора данных и прочитанные/записанные байты. Вы быстро найдете файлы, которые забиваются с помощью ввода-вывода. Иногда решения просты, например, перенос тысяч обновлений баз данных с помощью транзакции.

Answer 4

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

Скопируйте производственные данные в систему тестирования и убедитесь, что доступ к данным медленный, даже без высокой нагрузки. Если это - скорее всего плохой дизайн базы данных. Если это не так (то есть, если он становится медленным только под нагрузкой), то все сложнее. Если загрузка ЦП низка, но тяжелая загрузка системы вызывает замедление, тогда может возникнуть проблема с блокировками и ненужной блокировкой.Если загрузка процессора высока, это, вероятно, указывает на субоптимальный дизайн базы данных или плохое кэширование результатов (хотя обычно база данных должна делать это сама).

Зарегистрируйте журналы или попросите разработчиков зарегистрировать все запросы к SQL-запросам и их время выполнения. Если «всех» слишком много, попросите их записать только те, которые занимают больше 3 секунд для завершения. Вручную запускайте медленные запросы и попросите Oracle объяснить, что он делает.

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

Answer 5

OK. Я сделал это, и the basic method I use is this.

Вот пример the kind of results that are ultimately possible.

Это сказало, что это только начало.

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

Самая большая проблема заключается в том, что вы будете изолировать причину низкой производительности, , и для этого потребуется, чтобы одно или несколько приложений были закодированы немного (или много) по-разному. Вы столкнетесь с сопротивлением со стороны программистов, которые «владеют» кодом для внесения этих изменений. Это может очень сильно нарушить их смысл правильно разработанного кода, и это сложное чувство, которое нужно преодолеть.

Для примера я работал над приложением с серьезной проблемой производительности, которая считалась угрозой для компании. Как всегда бывает, существуют проблемы с Wild-XX-Guesses, и люди слишком охотно вкладывают время и деньги в эти догадки. Задача real была решением использовать XML в качестве формата связи между частями приложения, и большую часть времени он собирался генерировать и анализировать XML, , хотя две части приложения оказались в одном процессе и может обмениваться информацией напрямую. Чтобы изменить это, потребовалось изменение дизайна, что было не так сложно. Трудно было заставить программиста признать, что эта часть должна быть выполнена по-другому.

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

Это часть, которую я не понял, как преодолеть.