Мониторинг и настройка производительности
Оценить
(0 голоса)
Представьте себе, что вы являетесь консультантом по вопросам производительности. Вы посещаете клиента фирмы Sun - владельца какого-нибудь важного приложения БД. На пути к кофейному автомату в прихожей вас останавливает пара обеспокоенных системных администраторов. "Наш сервер БД работает просто ужасно. Не могли бы вы взглянуть на него?" - умоляют они. Что следовало бы сделать для локализации проблемы? Обычно этот вопрос задают претендентам на работу в группе Performance and Availability Engineering фирмы Sun. Иногда на этот вопрос можно услышать удивительные ответы. Кандидаты, которые только что закончили колледж, обычно хотят погрузиться прямо в исходный текст СУБД или операционной системы и выполнить его трассировку…
Оценить
(0 голоса)
Иногда в интервью кому-нибудь удается обрисовать надежную стратегию для локализации проблемы. Ответ мог бы выглядеть похожим на приведенный: "Сначала я пытаюсь получить некоторое общее представление о возникшей проблеме. Спрашиваю, что подразумевают системные администраторы, когда говорят "работает просто ужасно". Проблема заключается во времени отклика? Если это так, то насколько необходимо улучшить это время: на десять или на сто процентов? Затем я интересуюсь, когда возникла эта проблема. Случилось ли что-нибудь еще в то же самое время; возможно, что системные администраторы внедряли новую версию прикладного программного обеспечения или добавили к системе еще пятьдесят пользователей. Мои дальнейшие шаги будут зависеть от ответов на предыдущие…
Оценить
(0 голоса)
Весьма опасно просто строить предположения о характере возникшей проблемы. С этим приходится сталкиваться достаточно часто; автор и сам поступал подобным образом гораздо чаще, чем следовало бы. Секрет в данном случае заключается в том, чтобы отойти на шаг назад и удостовериться, что вы в состоянии увидеть картину целиком. Постарайтесь не потеряться в подробностях. Хорошей отправной точкой является постановка большого количества вопросов. Эти вопросы помогут понять: •             Как возникшая проблема проявляет себя. •             Чем характеризуется нормальное поведение системы. •             Когда впервые возникла проблема. •             Откуда было бы полезно начинать исследования. Некоторые люди имеют привычку неожиданно сообщать наиболее значительную информацию и только тогда,…
Оценить
(0 голоса)
На некотором этапе придет время проконтролировать систему. Необходимо знать, какие инструментальные средства мониторинга являются доступными, что следует искать в необъятном массиве данных, сгенерированных этими инструментальными средствами. В следующих главах описываются инструментальные средства мониторинга и пошаговые стратегии для обнаружения "узких мест", начиная с системы в целом и переходя к БД.
Оценить
(0 голоса)
К сожалению, хорошая производительность представляет собой цель, которую необходимо достичь, а не неотъемлемое конституционное право. И существует множество потенциальных ловушек на пути к этой цели. Некоторыми из наиболее распространенных проблем в средах серверов БД являются следующие: •             Несоответствующие аппаратные средства. •             Проблемы проектирования внутренней архитектуры операционной системы. •             Неудачно разработанные приложения и в том числе плохо написанные операторы языка SQL. •             Проблемы с пользовательским окружением. •             Неэффективность внутренней архитектуры в используемой СУБД. •             Неудачное размещение данных. •             Неудачный проект БД и его реализация, включая схему, выбор индексов и т.д. •             Настройка операционной системы. •             Настройка БД. В данной главе будут…
Оценить
(0 голоса)
Не принимайте решения о том, что ваши аппаратные средства имеют несоответствующую конфигурацию до тех пор, пока не будут исключены другие возможные причины. Проблемы, связанные с прикладными программами, могут быть основными причинами проблем производительности, и они представляют собой превосходную отправную точку для исследования. Начните с понимания имеющихся ограничений. Если только вы не являетесь разработчиком ядра, работающим для фирмы Sun или Oracle, то вы вероятно не сможете изменить внутреннюю архитектуру операционной системы или СУБД, так что исключите подобного рода амбиции из своего контрольного списка. Имеет смысл сосредоточиваться на тех проблемах, которые вы можете устранить, и обходить сто- роной проблемы, с которыми вы…
Оценить
(0 голоса)
Воздействие неудачно разработанного приложения на производительность может быть поистине удивительным. В крайних случаях производительность может значительно ухудшиться. Однажды на сайте одного из клиентов для испытания нового приложения под нагрузкой использовался эмулятор дистанционного терминала. При небольшом количестве пользователей система "вела себя" как обычно, но стоило лишь увеличиться нагрузке, как время отклика резко возросло, а производительность замедлилась до полного останова. В конечном счете удалось обнаружить причину этой проблемы после того, как было зафиксировано большое количество системных вызовов fork. Приложение протоколировало каждую транзакцию БД; в журнале фиксировались временная метка и номер терминала (tty), с которого подключался пользователь. Разработчик, который составил функцию протоколирования транзакций,…
Оценить
(0 голоса)
Превосходный с логической точки зрения проект может оказаться неэффективным при работе в условиях реальной нагрузки. Приходилось видеть примеры, когда широко используемый порядковый номер считывался и наращивался из одной и той же строки БД, к которой выполнялись интенсивные обращения, становясь в результате причиной "узкого места" производительности. Интенсивные операции вставки в таблицы также могут вызывать проблемы. Некоторые первоначальные инвестиции в профилирование производительности обычно стоят затраченных усилий также, как и независимый анализ опытных консультантов.
Оценить
(0 голоса)
Настройки пользовательского окружения (обычно они устанавливаются с помощью конфигурационных файлов .login, .cshrc или .profile) могут не показаться таким уж очевидным местом для того, чтобы искать здесь проблемы производительности. И все-таки система может быть повреждена неудачно созданными переменными окружения. В качестве примера можно привести случай, когда один из клиентов фирмы Sun был не в состоянии одновременно зарегистрировать 100 пользователей на своем сервере. Проблема, как оказалось, была заключена в переменной окружения PATH. Основные прикладные программы были размещены на другом сервере, доступ к которому осуществлялся с помощью автомонтировщика. Переменная окружения PATH сначала содержала указания на несколько различных, автоматически монтируемых каталогов и только после…
Оценить
(0 голоса)
Мы уже рассматривали необходимость тщательно спланированной стратегии размещения данных. Значение неудачных решений в данном случае нетрудно себе представить, тем более, что с ними так часто сталкиваются на практике! Если речь идет об использовании серийного программного обеспечения, то вам возможно и не потребуется настраивать свои приложения или схему БД. И даже если выполняется разработка собственного программного обеспечения, то вовсе не является ни реалистичным, ни необходимым добиваться идеальной производительности посредством настройки приложений и схемы БД. Правило 80/20 тоже применяется здесь, как в любом другом случае: 80 процентов усилий по настройке могли бы быть затрачены на то, чтобы добиться повышения производительности приложений на…
«ПерваяПредыдущая12345678910СледующаяПоследняя»
Навигация