Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle APEX Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
 Замедление заливки приложений APEX  [new]
VDom
Member

Откуда:
Сообщений: 51
Коллеги, есть непонятная ситуация.

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ами, и как с этим бороться?
6 июн 17, 15:01    [20543581]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 30336
VDom
Падает производительность приложений работающих с LOB, а таких у нас большинство.

почему? Зачем ва LOB?
VDom
Есть у кого нибудь идеи

Завист от того, хотите ли вы работать. Т.е. например, воспроизвести нагрузку на тесте можно многими способами и ПО для этого. Но вы не хотите(.
- прочитать ветку про "тормозит"
- перейти на версию апекса выше и подтягивать архитектуру под новые версии.
6 июн 17, 15:21    [20543665]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
SvDev
Member

Откуда: Челябинск
Сообщений: 1950
VDom,

Похоже больше на базу, а не на апекс, так что вам скорее в соседний раздел.
Может быть сервер или диск перегружены чем-то в это время ?

Если интересует сторона апекс, не уверен, что это может влиять напрямую, но рядом - сталкивался с утечкой TEMP памяти при использовании Text Field with autocomplete с опцией Lazy Loading: NO

Cессии отжирали неадекватное количество TEMP памяти и отваливались потом с ошибками, отловил в итоге виновника по V$ACTIVE_SESSION_HISTORY. Можно было так же наблюдать рост счетчиков в v$temporary_lobs для APEX_PUBLIC_USER между запросами.
6 июн 17, 15:51    [20543834]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
SvDev
Member

Откуда: Челябинск
Сообщений: 1950
VDom,

Я так понял у вас mod_plsql ?

Если не помогают другие средства отладки, и по словарям проблему не получается отследить (с вашими объемами), немного радикальный метод, но можно кильнуть все апексные сессии, они скорее всего должны восстановиться в рамках пула сессий (не помню, как с mod_plsql), но всякая память и ресурсы связанные с ними освободятся. Тогда сможете проверить, помогло или нет и влияют ли здесь утечки.

Можно какой-нибудь хитрый job написать, который бы давал сессиям таймаут.
6 июн 17, 17:04    [20544190]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Migelle
Member

Откуда:
Сообщений: 160
VDom,
А деградация идет только в апексовых сессиях, или в отдельных сессиях такая же картина? Если второе, то ИМХО апекс тут вообще не причем и с этим вопросом надо идти в ветку оракла.
6 июн 17, 17:27    [20544294]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
SvDev
Member

Откуда: Челябинск
Сообщений: 1950
Migelle,

Если это утечки ресурсов, например PGA или TEMP, другие сессии очень даже могут быть причем.
Самым простым способом утечки можно проверить - килянием.
6 июн 17, 17:32    [20544311]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Migelle
Member

Откуда:
Сообщений: 160
SvDev,

Ну, про ТЕМР автор сам написал, что не помогает. PGA явно проверяли на исчерпание.
У нас есть несколько проектов не на апексе, и коннекций сильно поменьше, веб-приложение общается с БД обменом CLOB-ами. Работает иногда годами без перезагрузки и деградации не наступает. Но все работает на 11.2, может 10.2 имеет в себе сей глюк.
6 июн 17, 21:19    [20544846]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
SvDev
Member

Откуда: Челябинск
Сообщений: 1950
Migelle,

то что ТС писал по поводу TEMP, это не совсем то. Утекшую TEMP память в пуле сессий фиг освободишь без убийства сессии, во всяком случае я не знаю как.

+
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> SELECT S.sid, S.serial#, SUM (T.blocks) * TBS.block_size / 1024 / 1024 used
_mb, T.tablespace
  2    FROM v$sort_usage T, v$session S, dba_tablespaces TBS
  3   WHERE T.session_addr = S.saddr
  4     AND T.tablespace = TBS.tablespace_name
  5     and s.sid = sys_context('userenv','sid')
  6   GROUP BY S.sid, S.serial#, TBS.block_size, T.tablespace;

no rows selected

SQL> declare
  2    t sys_refcursor;
  3
  4    i number;
  5  begin
  6    open t
  7    for
  8    with rownums
  9    as (select distinct
 10        rownum rn
 11          from dual
 12       connect by level <=1000000
 13    )
 14    select rn from rownums
 15     union all
 16    select rn from rownums;
 17
 18    fetch t into i;
 19    close t;
 20  end;
 21  /

PL/SQL procedure successfully completed.

SQL> SELECT S.sid, S.serial#, SUM (T.blocks) * TBS.block_size / 1024 / 1024 used
_mb, T.tablespace
  2    FROM v$sort_usage T, v$session S, dba_tablespaces TBS
  3   WHERE T.session_addr = S.saddr
  4     AND T.tablespace = TBS.tablespace_name
  5     and s.sid = sys_context('userenv','sid')
  6   GROUP BY S.sid, S.serial#, TBS.block_size, T.tablespace;

       SID    SERIAL#    USED_MB TABLESPACE
---------- ---------- ---------- -------------------------------
       264       9871         12 MY_TEMP

SQL>  alter system flush buffer_cache
  2  ;

System altered.

SQL>  alter system flush shared_pool;

System altered.

SQL> begin
  2    dbms_session.modify_package_state(DBMS_SESSION.FREE_ALL_RESOURCES);
  3  end;
  4  /

PL/SQL procedure successfully completed.

SQL> alter session set events '60025 trace name context forever';

Session altered.

SQL> SELECT S.sid, S.serial#, SUM (T.blocks) * TBS.block_size / 1024 / 1024 used
_mb, T.tablespace
  2    FROM v$sort_usage T, v$session S, dba_tablespaces TBS
  3   WHERE T.session_addr = S.saddr
  4     AND T.tablespace = TBS.tablespace_name
  5     and s.sid = sys_context('userenv','sid')
  6   GROUP BY S.sid, S.serial#, TBS.block_size, T.tablespace;

       SID    SERIAL#    USED_MB TABLESPACE
---------- ---------- ---------- -------------------------------
       264       9871         12 MY_TEMP

SQL> declare
  2    t sys_refcursor;
  3
  4    i number;
  5  begin
  6    open t
  7    for
  8    with rownums
  9    as (select distinct
 10        rownum rn
 11          from dual
 12       connect by level <=1000000
 13    )
 14    select rn from rownums
 15     union all
 16    select rn from rownums;
 17
 18    fetch t into i;
 19    close t;
 20  end;
 21  /

PL/SQL procedure successfully completed.

SQL> SELECT S.sid, S.serial#, SUM (T.blocks) * TBS.block_size / 1024 / 1024 used
_mb, T.tablespace
  2    FROM v$sort_usage T, v$session S, dba_tablespaces TBS
  3   WHERE T.session_addr = S.saddr
  4     AND T.tablespace = TBS.tablespace_name
  5     and s.sid = sys_context('userenv','sid')
  6   GROUP BY S.sid, S.serial#, TBS.block_size, T.tablespace;

       SID    SERIAL#    USED_MB TABLESPACE
---------- ---------- ---------- -------------------------------
       264       9871         24 MY_TEMP

SQL>

Тоже самое касается CACHE_LOBS.

Настройки в ords типа jdbc.MaxConnectionReuseCount не просто так делают.
7 июн 17, 10:04    [20545668]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
VDom
Member

Откуда:
Сообщений: 51
Коллеги, спасибо всем кто откликнулся.
К сожалению текущую работу никто не отменял, а она немаленькая, и оперативно отвечать на предложения не получается.

Поэтому отвечу всем сразу.

Без LOBов нельзя - логика приложения, хранятся сканы документов.
Нагрузку конечно можно попробовать воспроизвести, но для адекватных результатов надо бы и чтобы железо было одинаковое, а его нет.

На счёт тестовых серверов.
На самом деле тестовые сервера есть разные и на Linux Х_86_64 и на HP-UX Itanium (но железки с Itanium совсем чахлые).
Ни на одном из них деградации работы с LOBами не замечено. Правда там и нагрузки нет.
Есть идея запустить на самом загруженном сервере наш тест и посмотреть динамику. До сих пор мы этого не делали.

Перейти на более новые версии Апекса пока не можем. 5 Апекс например стаёт только на Oracle 12, а вопрос миграции и лицензирования зависит от заказчика.
Кроме того, это потребует некоторых ресурсов, человеческих и финансовых, а это опять зависит от заказчиков.

Похожий вопрос задан и в общей ветке Oracle.
Дисковая система не перегруженна, да и система в целом тоже.
Из 48 ядер в среднем занято 40.

Не думаю что виноват конкретно Апекс. Скорее всего это общая проблема LOB, а поскольку движок Апекса сам интенсивно работает с LOBами, то это сказывается и на нём. Однако нельзя исключать и того, что из-за интенсивной работы Апекса с LOBами общая нагрузка на LOBы сильно возрастает, и тогда проявляется проблема с LOBами.

Да у нас mod_plsql.
Регулярно перестартовываем Апачи, когда по разным причинам возростает нагрузка.
Нагрузка сразу падает, но дело в том что деградация с течение времени увеличивается.
В том числе и ночью когда Апекс нагрузки нет. Так что это врядли зависит от текущей нагрузки Апекса.

На счёт темпов и undo.
Проверяли так - создавали новое дефаултное ТП, а потом перестартовывали Апачи.
Все Апексные сессии отваливались, а потом продолжались с новыми ТП.
Никакого влияния на скрипт.
Есть некие колебания времени работы скрипта в течении суток, но в целом идёт рост времени.
7 июн 17, 13:15    [20546657]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
VDom
Member

Откуда:
Сообщений: 51
VDom,

Ещё раз, спасибо всем кто откликнулся.

Давайте не будем рассматривать работу с таблицами с LOBами, ограничимся нашим тестовым примером.
В примере есть только временный LOB. Время выполнения этого скрипта монотонно растёт…
Независимо от текущей мгновенной нагрузки на сервере.
Насколько я понимаю, ничего, кроме процессора, памяти, хранимых процедур и темпа в нём не используется.
Даже относительно ТЕМПа есть сомнения, т.к. темпLOB кэшируем и относительно невелик…
Создаётся впечатление, что какие-то структуры управления памятью, выделяемой под ТемпLOBы, не чистятся в процессе работы сервера, монотонно наращивая свой объём из-за чего теряется скорость обработки…
Как с этим бороться, непонятно…
7 июн 17, 15:57    [20547472]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
blkangel
Member

Откуда:
Сообщений: 1664
А если закрывать?

DECLARE 	
	zzz CLOB;
	xxx CLOB := 'asdasdasdasd';
BEGIN
	dbms_lob.createtemporary(zzz,TRUE);
	dbms_lob.open(zzz,dbms_lob.lob_readwrite);
	FOR i IN 1..10000 Loop
		dbms_lob.append(zzz, xxx);
	END LOOP;
	dbms_lob.close(zzz);
	EXCEPTION WHEN OTHERS THEN dbms_lob.close(zzz);
RAISE;
END;
/
7 июн 17, 16:10    [20547538]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
blkangel
Member

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

DECLARE
zzz CLOB;
xxx CLOB := 'asdasdasdasd';
BEGIN
dbms_lob.createtemporary(zzz,FALSE);

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;
/
7 июн 17, 16:12    [20547544]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
blkangel
Member

Откуда:
Сообщений: 1664
DECLARE 	
	zzz CLOB;
	xxx CLOB := 'asdasdasdasd';
BEGIN
	dbms_lob.createtemporary(zzz,FALSE);

	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;
/
/
7 июн 17, 16:13    [20547549]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
VDom
Member

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

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

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

Идея вполне здравая, если бы не… Вот время работы скрипта за сутки выросло раза в полтора… Или за неделю – в десять раз… Что с чем сравнивать? «Сейчас» с «сутки назад» или «неделю назад»? БД-то реально рабочая, за сутки меняется всё… Хотя… Если сохранять СГАСТАТ , скажем раз в 10 минут, а потом вдумчиво смотреть на колебания циферок… Например, выстроить графики по каждому параметру за месяц… Ох, не знаю, не знаю… :-/
7 июн 17, 16:58    [20547795]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 30336
VDom
До сих пор мы этого не делали.

сделайте. Это ваша обязанность. ПО для нагрузки есть.
VDom
но для адекватных результатов надо бы и чтобы железо было одинаковое, а его нет.

не надо. Вы и так увидите динамику по памяти и производительности.
VDom
Перейти на более новые версии Апекса пока не можем. 5 Апекс например

можете но не хотите. Апекс 4 от тройки отличается очень сильною. А вот 5 от 4 не сильно.
Т.е. вам надо перейти на 4-ку.
Либо жолго парить мозги вопросами с тройкой.

VDom
Без LOBов нельзя - логика приложения, хранятся сканы документов.

т.е. вы одной фразой отписались и хотите варианты решения вашей проблемы?
КОНКРЕТНЕЕ ЗАЧЕМ ЭТОТ ТИП ПОЛЯ НУЖЕН В ХРАНИМКЕ КРОМЕ ВЫГРУЗИТЬ НА КЛИЕНТА?

VDom
Похожий вопрос задан и в общей ветке Oracle.

ссылку пожалуйста. Может мы по второму кругу обсуждам.
7 июн 17, 21:50    [20548348]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 30336
VDom
Давайте не будем рассматривать работу с таблицами с LOBами, ограничимся нашим тестовым примером.

тогда это вопрос чисто ветки оракла. Дайте ссылку на то обсуждение.
Апекс ни при чём вроде.
7 июн 17, 21:54    [20548358]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
VDom
Member

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

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

Tunable Usage / Setting
=============================================
filecache_max 12156600320 / 12197325864
maxdsiz 8060928 / 2147483647
maxdsiz_64bit 190971904 / 274877906944
maxfiles_lim 922 / 63488
maxssiz 98304 / 134217728
maxssiz_64bit 2097152 / 1073741824
maxtsiz 13484032 / 1073741824
maxtsiz_64bit 369098752 / 8589934592
maxuprc 382 / 27000
max_thread_proc 193 / 3000
msgmbs 0 / 8
msgmni 2 / 4096
msgtql 0 / 30000
nflocks 132 / 30000
ninode 3862 / 484096
nkthread 2148 / 52516
nproc 870 / 30000
npty 0 / 200
nstrpty 2 / 200
nstrtel 0 / 60
nswapdev 1 / 32
nswapfs 0 / 32
semmni 132 / 30000
semmns 11705 / 60000
shmmax 104237301760 / 226158430208
shmmni 51 / 4096
shmseg 32 / 512

Из приведённого только 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 но ничего конкретного.

Складывается впечатление, что какие то структуры управляющие за управление памятью, с течением времени заполняются, в результате чего начинаются тормоза.
8 июн 17, 10:38    [20549175]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
VDom
Member

Откуда:
Сообщений: 51
В общей ветке это тема "Деградация производительности при работе с LOB"
http://www.sql.ru/forum/1262261/degradaciya-proizvoditelnosti-pri-rabote-s-lobami

Но в ветке Апекса намного больше предложений.

С переходом на новые версии Апекс не всё так просто.
Есть договор, в котором указано чего и какой версии должно быть.
В любом случае это решает заказчик, а его этот вопрос меньше всего волнует.
Кстати мы пробовали и 4 и 5 Апекс, так что мы готовы, но.

Приложение и написано для работы со сканами разных документов, в этом его смысл.
На самом деле мы вынесли из БД часть сканов (большую часть) в так называемый файловый архив.
Но проблема с LOB никуда не делась и не ушла.
Кроме того не забываем что у Апекса вся работа с файлами - загрузка/выгрузка, и собственно залмвка приложений всё идёт через таблицу WWV_FLOW_DATA с ITEM_VALUE CLOB.
Учитывая интенсивное использование приложений на апексе так или иначе возрастает работа с LOB.
Возможно достигается какой то порог, после чего начинаюся проблемы с LOB.
Хотя да, в этом случае это проблема БД, но не без участия Апекс.
8 июн 17, 11:29    [20549378]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
SvDev
Member

Откуда: Челябинск
Сообщений: 1950
VDom
Все Апексные сессии отваливались, а потом продолжались с новыми ТП.

т.е. прямое влияние апекса вы исключили, и всё говорит о том, что апекс ни при делах, проблема где-то на уровне базы в целом.
Свидетельств косвенного влияния вы не продемонстрировали, апекс используется как прослойка и лишь в части функционала. Я так понимаю, свидетельств, что виновата загрузка или выгрузка нет, я бы, например, подозревал манипуляции с Persistent LOBs и, в том числе, другие опции. Похоже на какой-нибудь баг.

VDom
Давайте не будем рассматривать работу с таблицами с LOBами, ограничимся нашим тестовым примером.

Если бы все было так просто, вы бы сами проблему легко воспроизвели, но тестовый пример проблемы роста времени выполнения, я так понимаю, не воспроизводит. Это значит, что виновато что-то что рядом, а рядом много чего, в SecureFiles and Large Objects Developer's Guide много красивых слов и опций, которые могут стрелять, например, только в комбинации, при наличии соответствующих багов на уровне оракла.

Соответственно, я не вижу сейчас смысла смотреть проблему в привязке к апексу, с учетом, что нет свидетельств, которые явно указывали бы на апекс, или что апекс ограничивает как-то отладку проблемы, которая проявляется на уровне базы и имеет общий характер.
8 июн 17, 12:37    [20549727]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 30336
VDom
Но в ветке Апекса намного больше предложений.

но честнее было сразу сказать, что апекс ни при чём и дать ссылку).
VDom
Приложение и написано для работы со сканами разных документов, в этом его смысл.

ну а апекс заточен на файловый архив. Есть разница?
VDom
Кроме того не забываем что у Апекса вся работа с файлами - загрузка/выгрузка, и собственно залмвка приложений всё идёт через таблицу WWV_FLOW_DATA с ITEM_VALUE CLOB.

не понял.
Я сразу перебрасываю сканы в свою таблу.
Никаких ваших ТАКИХ хранимок нету.
Что я делаю не так?
VDom
Учитывая интенсивное использование приложений на апексе так или иначе возрастает работа с LOB.

Мы про архитектуру вроде? Тогда огласите юз-кейс такой работы.
Возможно вы апекс используете не по назначению....при баге в самой СУБД.
8 июн 17, 13:08    [20549865]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
VDom
Member

Откуда:
Сообщений: 51
SDev

Да прямой связи с Апексом нет. Но косвенное очень даже может быть. Об этом я уже писал.
То есть сам движок Апекса очень интенсивно работает с LOB. Поэтому Апекс скорее катализатор а не причина, причина гдето в БД.
Мы тоже думаем что это может быть баг. Но реквесты, я создавать не могу. Да и даже если бы мог - Oracle 10 уже не поддерживается.

Почему мы сосредоточились на тестовом примере.
Во первых это объективный критерий по которому можно оценивать снижение производительности при работе с LOBами.
По времени срабатывания скрипта можно понять что БД пора перегружать.
Во вторых можно отбросить вопросы связанные с таблицами, их параметрами хранения и т.д. и т.п.
И даже в этом упрощонном примере непонятны причины.

У нас 10 БД поэтому SecureFiles нет.
И всё таки какая то коссвенная связь между Апексом и производительностью работы с LOB есть.
8 июн 17, 13:50    [20550035]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 30336
VDom
Почему мы сосредоточились на тестовом примере.

прогоните тесты на новых версиях БД и апекса.
Установка апекс 30 минут и установка БД 2,5 часа на ноуте.
С третьей версией апекса уже никто реально не работает.
8 июн 17, 13:56    [20550059]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
SvDev
Member

Откуда: Челябинск
Сообщений: 1950
VDom
И всё таки какая то коссвенная связь между Апексом и производительностью работы с LOB есть.

Если бы у вас были какие-нибудь объективные данные для этого утверждения, демонстрация связи запросами с проблемного сервера не было бы такой большой проблемой. Легко обвинить часть приложения, о которой не всё знаешь, но тем не менее это не конструктивный подход. Апекс действительно много работает с CLOB/BLOB и на уровне item в том числе, но и вы сами наверняка тоже с большими объемами LOB работаете. Часть с апекс отлажена большим числом людей с разными архитектурами приложений и pl/sql, часть с вашим приложением ограничена только вашей архитекторой с вашим кодом и отлажена хуже, чем apex сотрудниками oracle во всевозможных ситуациях. Тестовый пример никак не связан с апекс, поэтому, как минимум, я предлагаю вам собрать больше данных в другом разделе, чтобы появился хоть какой-то смысл смотреть конкретно что-то в привязке к апекс.

Прочего рода совета намного рациональнее обсуждать в разделе oracle.
8 июн 17, 14:44    [20550286]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
VDom
Member

Откуда:
Сообщений: 51
Petro123

Дело в том что на всех наших тестовых серверах, и на IA64 и на x86_64, время работы нашего тестового скрипта не растёт.
Так что нет смысла пробовать на других версиях БД или Апекса. На некоторых тестовых серверах даже работы выполняются, но нагрузка не соизмеримая.

Видимо дело всё таки в нагрузке.
8 июн 17, 17:44    [20551050]     Ответить | Цитировать Сообщить модератору
 Re: Замедление заливки приложений APEX  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 30336
VDom
Дело в том что на всех наших тестовых серверах, и на IA64 и на x86_64, время работы нашего тестового скрипта не растёт.

странно у вас с логикой.
Это ваше:
автор
Промоделировать ситуацию не удаётся, так как на тестовых серверах не удаётся организовать адекватную нагрузку.

говорит что тестовой площадки нормальой у вас НЕТ.
Вы не умеете её готовить.
А вы пишите что время скрипта не растёт.
Обычна лень. Уж извините.
Поэтому у вас даже у себя....без заказчика нет четвёрки.
8 июн 17, 20:22    [20551390]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Oracle APEX Ответить