DeepEdit!

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

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

Влияние измерителя

лияние измерителя

Любая прикладная программа, пытающаяся измерить длительность выполнения собственных подпрограмм, подвержена ошибке, называе­мой влиянием измерителя [Malony et al. (1992)]. Эффект влияния изме­рителя - это разновидность ошибки, возникающей из-за того, что длительность выполнения измеряемой подпрограммы отличается от дли­тельности выполнения той же подпрограммы, когда она не подвергает­ся измерениям. В последние годы у меня не было причин полагать, что эффект влияния измерителя сколько-нибудь заметно сказывался на проанализированных мною измерениях времени отклика Oracle. Од­нако знание этого эффекта помогло мне оспорить ошибочные аргумен­ты в отношении ненадежности временных характеристик функциони­рования Oracle.
Наша цель в том, чтобы определить, сколько времени заняло исполне­ние подпрограммы dosomething. Для этого снабжаем необходимыми инструментами нашу программу и получаем новую программу I:
Разберемся с эффектом влияния измерителя на примере. Пусть у нас есть такая программа U:

Мы ожидаем, что новая программа I выведет длительность выполне­ния dosomething. Но выводимое значение лишь приблизительно равно времени выполнения dosomething. Полученное значение e1 - e0, выра­женное в секундах, включает в себя не только продолжительность do_something, но и продолжительность одного вызова gettimeofday. На рис. 7.3 наглядно показано, почему так происходит.
Эффект влияния измерителя сказывается на результатах измерений следующим образом:
Время выполнения I превышает время выполнения на величину длительности двух выполнений gettimeofday.
Измеренная продолжительность dosomething в программе I превы­шает фактическое время выполнения dosomething на величину дли­тельности одного вызова gettimeofday.
Этот эффект минимален в тех приложениях, где длительность одного вызова gettimeofday мала по отношению к продолжительности любой измеряемой подпрограммы, подобной dosomething. Однако в системах с неэффективно реализованными вызовами gettimeofday (думаю, что так можно охарактеризовать версии HP-UX, предшествующие версии 10), эффект может быть значительным.
Рис. 7.3. Значение e1 -e0 лишь приблизительно равно длительности исполнения do_something; она также включает в себя полную длительность одного вызова gettimeofday (затененная область)
Эффект влияния измерителя относится к систематическим ошиб­кам. Систематическая ошибка является результатом погрешности эксперимента, которая постоянна от измерения к измерению [Lilja (2000)]. Постоянство влияния измерителя позволяет оценить его воз­действие на получаемые данные. Например, для того чтобы измерить эффект влияния измерителя ядра Oracle, вызванный вызовами gettim-eofday, необходимо знать две величины:
Количество вызовов таймера, которые ядро Oracle выполняет для определенной операции.
Ожидаемая продолжительность отдельного вызова таймера.
Зная частоту и среднюю продолжительность вызовов таймера для ядра Oracle, можно количественно оценить их влияние на измеряемую ве­личину. Влияние измерителя - это, вероятно, одна из причин потери времени, с которой мы сталкиваемся при отсчете времени в Oracle9вглаве 5.
Получить эти две характеристики несложно. Для того чтобы опреде­лить, сколько раз ядро Oracle вызывает таймер для заданного набора операций базы данных, можно обратиться к инструменту strace дан­ной платформы. Ожидаемая продолжительность одного вызова тайме­ра вычисляется с помощью программы, аналогичной коду, приведен­ному в примере 7.4. Этот код измеряет время выполнения нескольких последовательных вызовов gettimeofday, а затем вычисляет их сред­нюю продолжительность для указанного объема выборки.
В Linux, где я обычно провожу свои исследования (800 МГц Intel Pen­tium), этот код обычно дает значение задержки gettimeofday приблизи­тельно 2 мкс:
Эффект влияния измерителя во многом зависит от реализации опера­ционной системы. Например, на моем ноутбуке под управлением MS Windows 2000 (тоже 800 МГц Intel Pentium) время выполнения gettim-eofday составляет в среднем почти 6 мкс, т. е. эффект влияния измери­теля в 2,5 раза превышает эффект для Linux-сервера:
Экспериментируя подобным образом с системными вызовами, вы нач­нете понимать, в рамках каких ограничений приходится действовать разработчикам ядра в корпорации Oracle. Именно эффектом влияния измерителя объясняется то, что разработчики стремятся создавать инструменты для измерения времени только для тех событий, длитель­ность которых достаточно велика по сравнению с длительностью изме­рения. Компромиссное решение заключается в предоставлении полез­ной информации о времени без ухудшения производительности исследуемого приложения.

вызвана двойным учетом процессорного времени в правой части выра­жения. В терминологии ядра Oracle величина c содержит все время, проведенное в пользовательском и привилегированном режимах. Каж­дое значение ela включает в себя общее время, проведенное внутри из­меряемой последовательности инструкций ядра Oracle. Когда такая последовательность инструкций, снабженная измерительными сред­ствами, занимает ресурсы процессора, это будет учтено дважды.
Представьте себе, например вызов базы данных Oracle, выполняющий чтение диска (рис. 7.4). На рисунке исполнение вызова базы данных начинается в момент времени e0. В течение периода времени вызов потребляет процессорное время в пользовательском режиме. В момент времени ela0 процесс ядра Oracle совершает вызов gettimeofday, кото­рый предваряет выполнение события ожидания Oracle. В зависимости от операционной системы, выполнение системного вызова gettimeofday может на несколько микросекунд переводить процесс ядра Oracle в привилегированный режим, а затем возвращать его в пользователь­ский режим.

Некоторые реализации ядра Linux позволяют исполнять весь системный вызов gettimeofday в пользовательском режиме, что приводит к значительному улучшению производительности (один из примеров находится по адресу http://www-124.ibm. com/linux/patches/?patch_id=597).
Процесс в течение периода расходует процессорное время, находясь в пользовательском режиме, а затем переходит в привилегированный режим до завершения периода C. По завершении периода процесс яд­ра переходит в состояние ожидания и ждет результата запроса от диска.
После завершения запроса диск отправляет сигнал прерывания, вы­зывающий пробуждение процесса ядра Oracle, вследствие чего тот пе­реходит в состояние готовности к выполнению. На рис. 7.4 видно, что в этот момент времени процессор простаивает, а процесс сразу же обра­батывается планировщиком и переводится в привилегированный ре­жим. В этом режиме процесс Oracle обрабатывает результаты вызова дискового ввода/вывода, в частности, копирует данные из канала вво­да/вывода в пользовательскую область памяти процесса Oracle, на что уходит время D.
По завершении периода вызов чтения диска завершается, и процесс Oracle переходит в пользовательский режим на период времени E. Вмомент ela1 процесс Oracle фиксирует время завершения дискового чтения вызовом gettimeofday. Затем процесс Oracle приступает к выпол­нению оставшихся инструкций (также в пользовательском режиме), чтобы завершить вызов базы данных. Наконец в момент e1 обработка вызова базы заканчивается.
В результате этих действий ядро Oracle сформирует следующую стати­стику для вызова базы данных:
Чуть позже я подробно поясню, как именно вычисляется с. Значение c будет приблизительно равно сумме длительностей A, B, C, D, E и F. Наверное, вы уже поняли, где возникает двойной учет. Как значение ela, так и с, включают в себя длительности B, C, и E. Те участки ис­пользования процессора, которые оказались в пределах события ожи­дания, учтены дважды.
Насколько серьезна проблема двойного учета? К счастью, на практике ею обычно можно пренебречь. Наш опыт анализа более чем тысячи файлов трассировки в hotsos.com показывает, что длительности, поме­ченные как B, C, D и на рис. 7.4, обычно бывают небольшими. Дело в том, что время отклика (т. е. значение ela) измеряемых событий ожидания в Oracle8и Oracle9i, как правило, значительно превышает время использования процессора. В некоторых редких случаях (один из них мы вскоре рассмотрим) двойной учет проявляется в небольших фрагментах данных трассировки, но в общей схеме учета времени от­клика Oracle эффект двойного учета процессорного времени, как пра­вило, можно не принимать в расчет.


 









jAntivirus