Документация Oracle на русском языке





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

Главная :: Карта


Oracle Database или Oracle RDBMS — объектно-реляционная система управления базами данных компании Oracle.



 

DeepEdit!

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

  • Увеличить размер шрифта
  • Размер шрифта по умолчанию
  • Уменьшить размер шрифта

Мониторинг в UNIX


В UNIX имеется несколько инструментов, которыми можно пользоваться
для получения информации об ОС. Они доступны для самых разных вариантов
UNIX, и мы постарались проверить их все самым тщательным образом. К этим
инструментам относятся команды sar, vmstat, iostat, cpustat, mpstat, netstat,
top и        Обратите внимание, что внешний вид их выходных данных может
быть разным в зависимости от конкретного варианта используемого клона UNIX, поэтому мы рекомендуем ознакомиться 

с 

информацией о клоне UNIX в руководстве (страницы a.k.a).
Образцы команд и их параметры вместе с образцами выходных данных были выполнены на системе Sun Solaris (версии 2.61).
Многие операционные системы предлагают более продвинутые средства, например PcrfMon или Glance Plus, а некоторые компании продают инструмен­ты для экспресс-анализа мониторинга ОС. Мы хотели бы также знать, как скон­фигурированы аппаратные средства и операционная система, как много в ней оперативной памяти, сколько ЦП, контроллеров, дисков и дисковых групп и т. д. После того как нам удалось получить этот и предыдущие отчеты Oracle, пе­рейдем к идентификации узких мест.
Использование ЦП Для большинства клонов UNIX использование ЦП может быть измерено с помощью команды -u 5 1000. Команда .гаг является сокраще­нием от 

system activity reporter 

(составитель отчетов о деятельности системы). Ключ -и используется для измерения работы ЦП. Первое число означает часто­ту измерений (в секундах), а второе — количество повторений проводимых из­мерений для каждой частоты.
Одним из классических мифов об использовании ЦП является следующий:
у системы с нулевым        простоя ЦП процессор является узким местом.
Но правильно поставленный вопрос должен звучать следующим образом: как много процессов ожидает освобождения ЦП? Можно прекрасно работать с сис­темой, коэффициент простоя которой равен нулю, если при этом средняя дина очереди процессов, ожидающих освобождения ЦП, не превышает (2 х число
ЦП).
Замечание
Размер 

(2 

х число ЦП) используется уже на протяжении нескольких лет и основан на скоростях и архитектуре современных процессоров, персональном опыте и рекомендациях некоторых промышленных экспертов по UNIX. Это число является просто критерием, а не инструментом измерения с высокой степенью точности.
Если наша очередь готовых к выполнению работ не превышает названного
выше предела и процент простоя равен нулю, можно двигаться дальше, поско-
льку использованы все 100 процентов купленной системы. Ниже будет рассказа-
но, как с помощью команд vmstat или sar -q определить размер очереди готовых
к выполнению процессов системы. Если в среде        NT запустить Task Ma-
nager и выбрать в нем закладку Performance, можно в окне Processor Object уви­деть общие цифры производительности. Далее, можно разбить эти цифры на
следующие показатели: % привилегированного времени, % процессорного вре­мени и % времени пользователя, а также получить информацию об очереди, на­пример число отложенных вызовов процедуры в секунду (DPC Queued per second) и т. п. Вот пример выходных данных команды sar -и:
SunOS ganyirede 5.7        Generic sun4u 10/30/00
18:58:12       %usr        %sys            %wio        %idle
18:58:17          68        4              22        4
18:58:22          61        2              22        15
18:58:27          57        4              11        28
18:58:32          46        5              23        27
18:58:37           67        2                10        21
18:58:42           67        4                20        9
18:58:47          73        3              15        9
18:58:52          75        5               4        16
18:58:57          79        4              18        0
18:59:02          69        3              12        17
Average        66        4        16        14
Здесь использование ЦП разложено на следующие компоненты: %usr, %sys,
%wio и %idle. Первый компонент — %usr описывает процент времени, в тече-
ние которого ЦП задействован в пользовательских процессах (следует иметь в
виду, что здесь термин "процесс пользователя" рассматривается с точки зрения
операционной системы). Oracle при этом выступает как пользователь ОС. Вто-
рой компонент — %sys измеряет долю ЦП, необходимую операционной системе
для выполнения собственных работ (переключение контекстов, когда процессу
требуется операция ввода/вывода и процессор находится именно в его распо-
ряжении, или, наоборот, обработка прерываний, обслуживание сигналов и
т. д.). Третий компонент — %wio является мерой процессов, которые в настоя-
щий момент взаимодействуют с ЦП, но при этом ожидают выполнения постав-
ленных в очередь запросов ввода/вывода и вследствие этого не слишком
экономно используют ЦП. В зависимости от объема ввода/вывода и нагрузки
на систему всякий раз, когда процесс временно задерживает ЦП (потому что
должен произвести операцию ввода/вывода), ОС производит переключение
контекста путем отъема ЦП у этого процесса и передачу его какому-либо друго-
му процессу в очереди. Когда первоначально упоминавшийся процесс закончит
операцию ввода/вывода, он снова станет в очередь готовых к выполнению про-
цессов, чтобы получить очередную порцию процессорного времени. Можно
рассматривать        либо как непроизводительное использование ЦП, либо
как потенциальное время простоя. И, наконец, четвертый компонент — % idle означает процент доступности ЦП, или, если говорить проще, процент неиспо­льзуемых возможностей ЦП.
Сумма значений столбцов %sys и %wio для любой из строк не должна превы­шать 10—15%. Если вы регулярно замечаете, что эта цифра выше названной ве­личины, значит, настраиваемая система испытывает чрезмерно высокое число переключений контекстов и прерываний (%sys), а также значительное число ожиданий ввода/вывода (%wio). Если наблюдаются такие высокие цифры, по­старайтесь найти причину их появления. В 99 случаях из 100 это будут пробле­мы приложения.
Использование устройств Для получения цифр использования устройств до-
статочно выполнить команду sar -d 

1000. Эта команда предоставляет полезную
информацию об имени устройства, проценте занятости названного устройства,
средней длине очереди к устройству (avque), количестве операций чтения и за-
писи в секунду (r+w/s), переданных блоках (blks/s в 512-байтовых порциях),
среднем времени ожидания для каждой операции ввода/вывода в течение 5-се-
интервала измерения производительности        в миллисекундах) и
среднем времени ожидания, необходимом для обслуживания операции вво­да/вывода (avserv). Повторим, что сопоставимые установки и значения доступ­ны в среде монитора производительности Windows NT для объекта Logical Disk Object.
Использование устройств начинает отличаться от оптимального после того, как процент использования устройства (%busy) превысит 60%. Кроме того, имеется прямая корреляция между увеличением процента занятости и средней длиной очереди к устройству, средним временем ожидания и средним временем
обслуживания (avque, avwait и avserv). Для современных дисковых систем (с до-
статочно большим размером дискового кэша) значение avserv порядка 100 млс
высоким. Если в настраиваемой системе встречаются такие
значения, необходимо определить причины их возникновения.

Замечание
Если у вас используются системы памяти от третьих фирм,

необходимо вложить деньги в приобретение инструментальных средств, которые предоставят сведения о дисковых массивах. Это связано с тем, что, как оказалось, информация, получаемая для дисковых массивов при выполнении команды sar -d, не является достоверной. В соответствии с ней мы, якобы, никогда не наблюдаем реальной конкуренции за ввод/вывол и узких мест, даже в тех случаях, когда точно известно, что они есть. Доказательства их существования можно найти с помощью событий ожидания Oracle. Этот феномен обязан своим появлением наличию нескольких уровней кэша между тем, что рассматривается как устройство
операционной системы, и тем, что в действительности является диском устройства массовой памяти.
 



jAntivirus