Выявления проблем производительности на серверах БД

Оценить
(0 голоса)

Итак, время пришло. Вооружившись только собственным разумом, добавив к нему немного здравого смысла и некоторые основные знания системы, вы собираетесь справиться с проблемой производительности, от которой страдает ваш сервер баз данных. Засучите рукава и поудобнее устраивайтесь перед клавиатурой. Группа немного напуганных коллег смотрит широко открытыми глазами из-за вашего плеча.

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

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

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

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

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

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

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

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

Подробнее в этой категории: Первый этап. Мониторинг памяти »
Первый этап. Мониторинг памяти
Нормальное замещение страниц до Solaris 8
Приоритетное замещение страниц
Файлы UFS и замещение страниц
Нормальное поведение замещения страниц, начиная с операционной системы Solaris 8

Добавить комментарий


Защитный код
Обновить