Неудачное размещение данных

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

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

Если речь идет об использовании серийного программного обеспечения, то вам возможно и не потребуется настраивать свои приложения или схему БД. И даже если выполняется разработка собственного программного обеспечения, то вовсе не является ни реалистичным, ни необходимым добиваться идеальной производительности посредством настройки приложений и схемы БД. Правило 80/20 тоже применяется здесь, как в любом другом случае: 80 процентов усилий по настройке могли бы быть затрачены на то, чтобы добиться повышения производительности приложений на оставшиеся 20 процентов. Сосредоточьтесь на устранении основных "узких мест".

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

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

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

На сегодняшний день для операционной системы Solaris доступно множество инструментальных средств мониторинга. Коммерческие инструментальные средства, такие как ВМС Best/1, предлагают емкие функциональные возможности планирования работы и усложненные возможности мониторинга. Инструментальные средства ВМС Patrol и другие аналогичные инструменты предлагают механизмы событий, уведомляющие пользователя, если происходит некоторое исключительное событие. Все коммерческие инструментальные средства автоматически строят графики ключевых элементов поведения операционной системы, таких как использование ресурсов ЦП.

Другим широко используемым инструментальным средством является virtual_adrian.ee, которое разработано Адрианом Коккрофтом (Adrian Cockcroft) и основано на инструментарии SE (Standard Edition - стандартного издания); оба инструментальных средства доступны на Web-сайте настоящей книги. Утилита virtual_adrian.se контролирует все важные элементы производительности системы и подсказывает пользователю, какой из них заслуживает повышенного внимания. Инструментарий SE и virtual_adrian подробно описываются в книге Адриана Коккрофта и Рича Петтита (Rich Pettit) Sun Performance and Tuning, Second Edition, Sun Press.

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

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

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


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