Коллеги, есть непонятная ситуация.

HP-UX 11.31 Itanium Memory – 200+ G
DB – 10.2.0.5 Size – 10+ Tb
Все возможные патчи на БД поставлены.

Нагрузка - 1000-1800 (50-100 активных сессий), плюс джобы подготавливающие отчёты, загрузки данных, то-сё…
Основное приложение написано на АПЕКС 3.1.2.00.02. Раздельная инсталляция - БД на одном сервере, Апач на другом.

После старта экземпляра всё работает нормально, однако через неделю-две производительность сильно снижается!
Падает производительность приложений работающих с LOB, а таких у нас большинство.
В частности, это проявляется в черезвычайно длительной процедуре заливки новых версий Апекс приложений.
Если вначале это минуты, то по прошедствии времени, при деградации производительности с LOB, это длится часами, или вообще не заканчивается.
С нашей точки зрения, это следствие всё той же деградации производительности с LOBами.

Причина этого явления непонятна. Единственный способ который реально помогает - перегрузка БД.
Сами понимаете, что это не метод.
При этом это не латчи, и не блокировки - чистое время процессора.
Смена TEMP & UNDO tablespace’ов, alter system flush - и другие приседания и камлания эффекта не дают.
В инете ничего на эту тему нарыть не удалось.
В основном это банальные советы, типа не делайте много мелких изменений LOB, накопите в переменной и пишите максимально большими кусками.
Но это не объясняет причину снижения одних и тех же операций с LOB со временем.

Конкретный тестовый пример простейший. Берём блок :
set timing on;
set serveroutput on
DECLARE
zzz CLOB;
xxx CLOB := 'asdasdasdasd';
BEGIN
dbms_lob.createtemporary(zzz,TRUE);
FOR i IN 1..10000 Loop
dbms_lob.append(zzz, xxx);
END LOOP;
dbms_lob.freetemporary(zzz);
EXCEPTION
WHEN OTHERS THEN
dbms_lob.freetemporary(zzz);
RAISE;
END;
/

После старта экземпляра время его выполнения ок. 0.2 с.
Темп деградации – примерно в 10 раз в неделю. Через неделю примерно 2 сек., через 2 недели – 10-20 и т.д.
Естественно, ждать, пока замедлится на 3-4-5 порядков, возможности нет, приходится экземпляр перезапускать.
И опять – всё возвращается к описанной картине.

Никакой корреляции с платформой, версией ОС, спецификой АПЕКС, версией БД установить не удалось.
Промоделировать ситуацию не удаётся, так как на тестовых серверах не удаётся организовать адекватную нагрузку.
Таким образом на тестовых серверах, подобная ситуация не воспроизводится.
Уточняю, что тестовая среда на Linux x86_64. Так что нельзя исключать зависимость от платформы.

Есть у кого нибудь идеи из-за чего может происходить деградация работы с LOBами, и как с этим бороться?

AlexFF__|, По поводу swap сказать ничего не могу. Если бы это был Linux, то вопросов бы не было :
top
swapoff -a
swapon -a
и проблема былабы решена.
Но это HP-UX а тут всё не так :-(( просто
Ставил систему инженер из HP, специалист по Oracle.
Ситуацию с нагрузкой у нас он знает, как настраивать HP-UX чтобы не было свопа, он точно знает, так что это врядли.
К сожалению я не знаток HP-UX, чтобы в этом убедиться лично.
Но идея принимается - надо убедиться что свопа нет и что он не растёт.

У заказчика давно нет поддержки :-(
Но доступ на Металинк у нас есть.
Реквестов создавать не могу :-((

Информации о проблеме и на Металинке найти не удалось.

landy,
sdp11:/ # swapinfo -tam
Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 32768 89 32679 0% 0 - 1 /dev/vg00/lvol3
reserve - 20757 -20757
memory 387743 262227 125516 68%
total 420511 283073 137438 67% - 0 -

Я так понял что своп на /dev/vg00/lvol3 как видите он не используется - PCT USED = 0

Takurava,
Вы понимаете, особо трассировать не чего
Ну говорит что всего один курсор

Вы обратите внимание что наш тестовый пример вообще не работает с таблицами




То есть идёт работа с LOB чисто в памяти, и тем не менее именно на этом примере видна деградация скорости работы с LOB

VDom,

В примере есть только временный LOB, никаких таблиц не используется.
Время выполнения этого скрипта монотонно растёт…
Независимо от текущей мгновенной нагрузки на сервере.
Насколько я понимаю, ничего, кроме процессора, памяти, хранимых процедур и темпа в нём не используется.
Даже относительно ТЕМПа есть сомнения, т.к. темпLOB кэшируем и относительно невелик…

Создаётся впечатление, что какие-то структуры управления памятью, выделяемой под ТемпLOBы, не чистятся в процессе работы сервера, монотонно наращивая свой объём из-за чего теряется скорость обработки…
Как с этим бороться, непонятно…

VDom,
«Так же попробуйте отказаться от Кэш, замедлит общий темп, но возможно на длительную работу не скажется.»

Увы, время сразу возрастает примерно в 100 раз, что неприемлемо…
Кстати, время без кэша растёт примерно в той же пропорции, что и с кэшем. Только по абсолютному значению раз в сто больше…

“Сравнить состояние до и после через "AWR : Compare period reports" пробовали?
Посмотреть на v$sgastat - если какие-то "структуры управления памятью" растут, может их поискать?”

Идея вполне здравая, если бы не… Вот время работы скрипта за сутки выросло раза в полтора… Или за неделю – в десять раз… Что с чем сравнивать? «Сейчас» с «сутки назад» или «неделю назад»? БД-то реально рабочая, за сутки меняется всё… Хотя… Если сохранять СГАСТАТ , скажем раз в 10 минут, а потом вдумчиво смотреть на колебания циферок… Например, выстроить графики по каждому параметру за месяц… Ох, не знаю, не знаю… :-/

Деградация носит кумулятивный характер, поэтому надо понять что может иметь кумулятивный характер, и может ли это быть связанно с операциями с LOB.
С моей точки зрения это :

1) сегментация TEMP табличного пространства - замена табличного пространства TEMP на другое ничего не даёт поэтому этот фактор исключаем
2) рост swap памяти - проверка показала что свопа нет и он не растёт
3) переполнение каких то счётчиков, или семафоров -
В HP-UX есть заклинание kcusage показывающее пороговые значения и текущие

Из приведённого только filecache_max наводит на размышления.
Он достиг 12156600320 при пороге 12197325864. Разница 40 725 544. Вроде много, но это 0,34% !! Это настораживает.
Вообщето в БД у нас 187 ТП, а у них 592 файла. И это без всяких других файлов БД (онлайн журналов и т.д.).
Непонятно только как это может влиять на LOB.

4) сегментация памяти - мне кажется что это кандидат №1

Поясню почему.
Есть такое понятие как управление большой памятью. Памяти у нас действительно много, и я даже не всю её использую.
System Page Size: 16Kbytes
Memory: 261149792K (137296352K) real, 265148832K (139316016K) virtual, 105355568K free Page# 1/893

В связи с этим вспоминаем что есть такая вещь как HugePages, которую как раз и рекомендуется использовать при большой памяти.
То есть при старте память для Oracle сразу выделяется одним непрерывным куском, а внутри этого куска управление памятью выполняется максимально большими страницами.
Всё это хорошо описано, и я неоднократно это настраивал но под Linux.
Специалисты по HP-UX говорят что в HP-UX нет понятия HugePages и что там всё изначально делается правильно??
Но как? Толком мне никто этого так и не пояснил. В инете есть какие то упоминания о HugePages и HP-UX но ничего конкретного.

Складывается впечатление, что какие то структуры управляющие за управление памятью, с течением времени заполняются, в результате чего начинаются тормоза.

dba123
Что сессия, что dbms_lob.call - все равно временные лоб-сегменты освободятся только после закрытия сессии.
Возможно, что такой пул иногда надо останавливать или реально освобождать с помощью евента 60025, если дело в ТЕМР ТС(v$sort_usage)
имхо, создать тест-пул, запустить через а ля run_stats(Кайт)


Спасибо за идею. Не уверены что event 60025 есть в Oracle 10. Будем пробовать.