Аналитические стратегии производительности
Я присвоен performance-tuning-debugging-troubleshooting задаче.
Сценарий: среда несколько приложения, работающая на нескольких сетевых базах данных использования машин. ОС является Unix, DB является Oracle. Бизнес-логика реализована через приложения с помощью синхронной / асинхронной передачи. Приложения являются многопользовательскими с несколькими сотнями пользователей центра обработки вызовов в пиковое время. Пользовательские интерфейсы веб-.
Приложения являются третьим лицом, я могу получить доступ к разработчикам и исходному коду. У меня только есть производственная система и среда функционального испытания, никакая среда нагрузочного теста.
Проблема: плохая производительность! Мне нужны быстрые результаты. Management сходит с ума.
Я получил примеры признака как они: действия пользовательского интерфейса, занимающие минуты для завершения. Seaching для клиента обычно занимает 6 секунд, но непосредственный последующий поиск с теми же параметрами может занять 6 минут.
Какова была бы Ваша стратегия нахождения первопричин?
5 ответов
Если это сценарий типа 11-го часа, и это система, к которой вы подходите без предварительных знаний, я бы сделал следующее: конкретные инструкции ниже предназначены для unix newb, но общие принципы подходят для любой системной сортировки:
- Создайте текстовый файл с именем каждого из ваших производственных хостов в нем. Назовем это
prodhosts - . Получите ваш открытый ключ ssh на
~ / .ssh / authorized_keysна каждом изprod_hosts. Если вы не знакомы с агентами ssh и не знакомы с тем, как быстро выполнять вход в систему, найдите 10 минут и прочтите об этом или воспользуйтесь сценарием , который сделает это за вас . Проверить загрузку системы на всех серверах
для i в `cat prodhosts`; сделать echo $ i; ssh $ i время безотказной работы; doneВысокая средняя нагрузка (в общем, больше, чем количество ядер, которые у вас есть) указывает на проблемные серверы. Запишите их - скоро вы их увидите.
Проверять полные диски - это очень часто
для i в `cat prodhosts`; do echo $ i; ssh $ i df -h; doneЛюбой хост, который на 100% или почти полностью использует диск, будет проблемой. Запишите все проблемные серверы, которые вы обнаружите таким образом.
Проверка активности подкачки - подкачка является наиболее частой причиной плохой производительности (и обычно она сочетается с указанным выше индикатором высокой средней нагрузки).
вместо i в "cat prodhosts"; do echo $ i; ssh $ i бесплатно -m; doneЭто покажет вам, сколько памяти есть у всех ваших ящиков и сколько они меняют местами.Вот как может выглядеть работоспособная система с примерно 16 ГБ ОЗУ:
общее количество используемых свободных общих буферов, кэшированных Mem: 15884 15766 117 0 61 14928 - / + buffers / cache: 776 15107 Обмен: 31743 0 31743Скорее всего, в столбце
использованодля обмена будет большое число ваших проблемных окон. Это объем памяти, который пытаются использовать ваши приложения, которого нет на вашем компьютере.Вооружившись этой информацией, вы должны иметь лучшее представление о том, где находится узкое место в 95% всех систем (оставшиеся 5% будут замедлены из-за удаленных сетевых ресурсов или гремлинов). Теперь вы проводите стандартную сортировку. Начните с нижней части стека - то есть, если у вас везде высокая нагрузка и плохая производительность, начните с вашей базы данных, потому что вполне вероятно, что ее проблемы каскадно распространяются повсюду (если ваша БД работает нормально, очевидно, сначала посмотрите в другом месте, но всегда с подозрением относитесь к базам данных, когда на кону производительность):
- База данных - получите журнал всех выполняемых запросов, которые занимают, скажем, 400 мс, за такой большой период выборки, который вы можете себе позволить (в идеале эти журналы уже будут существовать, в противном случае соберите их вместе и позвольте данным собираться в течение часа или около того). Составьте несколько сценариев, которые нормализуют запросы, и выясните, какие запросы занимают больше всего общего времени в вашей системе (также будьте осторожны, чтобы не пропустить дрянные одноразовые запросы, которые занимают слишком много времени и замедляют все остальное. ).Вы захотите проанализировать эти запросы с помощью плана объяснения и выяснить, как заставить их лучше попадать в индексы, или выяснить, как вообще удалить их из вашей системы, если это возможно. Обратитесь за помощью к администратору баз данных, если он у вас есть, и используйте стандартный анализатор журнала запросов, если можете.
- Приложение - просматривайте журналы и не упустите ничего безумного. Приложения и ведение журнала сильно различаются, поэтому это очень зависит от системы.
- Операционная система (используйте это на любом компьютере) - посмотрите на вывод
dmesgна вашем компьютере - есть ли какие-либо предупреждения? Полистайте логи в / var / log - ничего интересного не видите? Какие-нибудь журналы лопаются при кажущемся? Это ваши проблемные моменты.
После того, как вы выполнили быстрый и беспрепятственный взлом, чтобы вернуть систему в стабильное состояние, сядьте и поговорите с «менеджментом» о мониторинге, анализе журналов и всех стандартных инструментах торговли сисадминами, которые должны помочь предотвращать возникновение сценариев, подобных тому, в котором вы находитесь. Прочтите о Nagios, Munin, rsyslog и т. Д. И т. Д. Или наймите кого-нибудь, кто сможет автоматизировать ваш центр обработки данных и его мониторинг для вас. Кроме того, если приложение является сторонним лицом, поговорите с ними о том, как они ожидают, что вы будете справляться с подобными ситуациями - если это уже готовый продукт, у них должны быть инструкции по требованиям, необходимым для успешного запуска их приложения. Если вы наняли для строительства случайную компанию-подрядчика, подумайте о том, чтобы порекомендовать руководству нанять людей, которые знают, что делают.
Запустите монитор файлов sysinternals и монитор процессов, чтобы обнаружить чрезмерное количество операций ввода-вывода. Легче всего сделать, когда производительность затягивается при запуске определенных отчетов или программ. Сотрудничайте со своим администратором баз данных Oracle для мониторинга производительности базы данных. Сотрудничайте с системным администратором для наблюдения за дисками, на которых находятся таблицы Oracle. Вы ищете плохо выполняемые запросы, приводящие к полному сканированию таблиц, результатам матриц и т. Д. Системный администратор / netadmin должен отслеживать насыщение сети.
Скопируйте производственные данные и код в другую изолированную тестовую систему и измерьте производительность. Посмотрите, где производительность ЦП и дисков зашкаливает.
Обратите внимание, что вывод FileMonitor имеет формат .csv и быстро переполнит Excel. Но Excel может рассматривать этот .csv как внешний источник данных, и вы можете подключить его к сводной таблице. Просто используйте мастер сводной таблицы, укажите файл отчета (.txt) и измерьте имя приложения, имя файла набора данных и количество прочитанных / записанных байтов. Вы быстро найдете файлы, которые забиваются с помощью ввода-вывода. Иногда решения просты, например, обертывание тысяч обновлений базы данных транзакцией.
Проверьте загрузку процессора, если она низкая, похоже, это проблема базы данных, проанализируйте запросы и поищите последовательные сканирования, возможно, не хватает только индекса.
Проверьте, какой компонент простаивает, возможно, есть какой-то таймаут или не хватает ресурсов.
Все остальное зависит от архитектуры приложения. Вам определенно нужна тестовая среда, чтобы создать достойный бенчмарк, в качестве альтернативы пусть менеджеры (которые купили это оборудование) заплатят за поддержку сторонних производителей.
Хорошо. Я сделал это, и основной метод, который я использую, - это .
Вот пример результатов, которые в конечном итоге возможны .
Тем не менее, это только начало.
Возникнет множество проблем, и каждая из них, которую вы обнаружите и исправите, значительно улучшит ситуацию, но вы не закончите. Вы должны получить большинство из них.
Самая большая проблема будет заключаться в том, что вы определите причину низкой производительности, и для этого потребуется, чтобы одно или несколько приложений были закодированы немного (или много) иначе. Вы столкнетесь с сопротивлением со стороны программистов, которые «владеют» кодом, чтобы внести эти изменения. Это вполне может нарушить их понимание правильно спроектированного кода, и это чувство сложно преодолеть.
Например, я работал над приложением с серьезной проблемой производительности, которая считалась опасной для компании. Как всегда бывает, существуют дикие-XX-догадки относительно того, в чем проблема, и люди слишком охотно вкладывают время и деньги в эти догадки.Реальная проблема заключалась в решении использовать XML в качестве формата связи между частями приложения, и большую часть времени уходило на создание и анализ XML, даже несмотря на то, что две части приложения имели место быть в одном процессе и напрямую обмениваться информацией. Чтобы изменить это, потребовалось изменение конструкции, что было несложно. Трудно было заставить программиста признать, что эту часть нужно делать по-другому.
По моему опыту, наиболее серьезные проблемы с производительностью вызваны чрезмерно общими подходами к абстракции и структуре данных, которым религиозно обучают и которые программисты крайне неохотно пересматривают.
Это та часть, которую я не понял, как преодолеть.
Посмотрите, на какой машине (машинах) загрузка процессора высока - таким образом вы, вероятно, сможете определить, является ли проблема на стороне базы данных или в коде пользовательского интерфейса (последнее довольно маловероятно, но все же стоит проверить). Также проверьте, не не хватает ли какой-либо машине памяти (способ проверки зависит от языка программирования), т.е. не вызвано ли замедление работы постоянной подменой виртуальной памяти.
Скопируйте производственные данные в тестовую систему и проверьте, медленный ли доступ к данным даже без высокой нагрузки. Если да - скорее всего, это плохой дизайн базы данных. Если это не так (т.е. доступ становится медленным только под нагрузкой), то все гораздо сложнее. Если загрузка процессора низкая, но сильная нагрузка на систему вызывает замедление, то, возможно, проблема в блокировках и ненужной блокировке. Если загрузка процессора высокая, то это, вероятно, указывает на неоптимальный дизайн базы данных или плохое кэширование результатов (хотя обычно база данных должна делать это сама).
Проверьте журналы или попросите разработчиков записать в журнал все SQL-запросы и время их выполнения. Если "всех" слишком много, попросите их регистрировать только те, на выполнение которых уходит, скажем, более 3 с. Вручную запустите медленные запросы и попросите Oracle объяснить, что он делает.
Вручную проверьте базу данных на наличие таблиц с явно отсутствующими индексами. Если таблиц немного, то обычно это можно сделать быстрее, чем искать медленные запросы.