Что я и говорил - все слова знакомы, а вот действия отличаются.
Все-таки unix-unix'у рознь. Нельзя оперировать понятиями - я знаю oracle или unix. Конкретные инкарнации - еще куда не шло, а все скопом - не бывает.
Оказывается что в состав Excel входит так называемый Пакет анализа.
Оказалось, очень полезная штука. Поспорили мы тут на днях, а имет ли отношение изменение параметра XXX к изменению загрузки cpu:sys.
Замеряли, до и после, все как надо.
Затем загнали sar в Excel, затем Анализ Данных, описательная статистика. Вот тебе и среднее, и стандатное отклонение, и стандартная ошибка, минимум, максимум - все сразу и мгновенно. Тут же видно, имеют ли два набора отклонения в рамках ошибок, или нет.
Если нет - значит эффект есть, иначе - погрешность измерений.
Средства, включенные в пакет анализа данных, доступны через команду Анализ данных меню Сервис. Если эта команда отсутствует в меню, в меню Сервис/Надстройки необходимо активировать пункт "Пакет анализа".
Очень рекомендую.
Начиная с версии 9i свято верил, что pga_aggregate_target был сделан для того,
чтобы не уводить систему в swap, когда выставили слишком большое число sort_area_size.
Вроде бы Oracle не должен захватывать памяти, больше чем pga_aggregate_target.
И действительно, в 9i такого не встречалось.
Однако в 10.1 при выставленных 6 Gb памяти, Oracle спокойно отъедает 12gb !!!
Читаем документацию
"
total PGA allocated: This gives the current amount of PGA memory allocated by the instance. Oracle tries to keep this number less than the value of PGA_AGGREGATE_TARGET. However, it is possible for the PGA allocated to exceed that value by a small percentage and for a short period of time, when the work area workload is increasing very rapidly or when the initialization parameter PGA_AGGREGATE_TARGET is set to a too small value.
"
Ни фига себе "small percentage", в 2 раза !
В statspack видим
"warning: pga_aggregate_target was set too low for current workload, as this value was exceeded during this interval"
Оказывается, это сообщение появляется если за наблюдаемый период over allocation count из v$pgastat был > 0.
Ну а раз так, отхватим еще памяти.
Правда если посмотреть в PGA Memory Advisory, то 99.99% проходов уложились в Optimal Executions.
Типа со стороны Oracle все нормально, а то что это в swap'е это никого не волнует.
Выводы:
1. Oracle молодец, быстро успевает захватывать доп. память.
2. Бороться с этим эффектом похоже бесполезно, документация советует
"
If over-allocation occurs, you should increase the value of PGA_AGGREGATE_TARGET using the information provided by the advice view V$PGA_TARGET_ADVICE
"
Возможно (это догадка), что дело опять в параметрах _smm_max_size (_pga_max_size)
Don Burleson, ссылаясь на чужую статью
http://www.dba-oracle.com/oracle_news/2005_12_19_10g_release_changes.htm
Рассказывает что в 10gR2 поменяли внутренние лимиты на _smm_max_size.
Возможно эта работа началась еще в 10gR1.
И значит, если нет доп. памяти, увидев, что PGA растет такими темпами, есть активность swap,
надо зажимать _smm_max_size.
Для того чтобы замерить скорость отчета удобнее всего воспользоваться timex.
timex -opt sqlplus login/password @test.sql
Однако чтобы получить полные данные нужно включить accounting Solaris
root@sf2:/[518]# /etc/init.d/acct start
Важные дополнения:
Ключ timex -s позволит распечатать системную статистику, которая может быть очень полезной при анализе расхождения времен.
Не забудьте выключить accountинг после эксперимента
root@sf2:/[519]# /etc/init.d/acct stop
И наконец, великий Adrian Cockcroft почти 7 лет назад рассказал
что анализ account эга позволяет сделать нам профиль нагрузки приложения !
http://www.sun.com/blueprints/1099/workload.pdf
Сообщения
Все комментарии
