Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Коллеги, есть непонятная ситуация. 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ами, и как с этим бороться? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 15:01 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDomПадает производительность приложений работающих с LOB, а таких у нас большинство. почему? Зачем ва LOB? VDomЕсть у кого нибудь идеи Завист от того, хотите ли вы работать. Т.е. например, воспроизвести нагрузку на тесте можно многими способами и ПО для этого. Но вы не хотите(. - прочитать ветку про "тормозит" - перейти на версию апекса выше и подтягивать архитектуру под новые версии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 15:21 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDom, Похоже больше на базу, а не на апекс, так что вам скорее в соседний раздел. Может быть сервер или диск перегружены чем-то в это время ? Если интересует сторона апекс, не уверен, что это может влиять напрямую, но рядом - сталкивался с утечкой TEMP памяти при использовании Text Field with autocomplete с опцией Lazy Loading: NO Cессии отжирали неадекватное количество TEMP памяти и отваливались потом с ошибками, отловил в итоге виновника по V$ACTIVE_SESSION_HISTORY. Можно было так же наблюдать рост счетчиков в v$temporary_lobs для APEX_PUBLIC_USER между запросами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 15:51 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDom, Я так понял у вас mod_plsql ? Если не помогают другие средства отладки , и по словарям проблему не получается отследить (с вашими объемами), немного радикальный метод, но можно кильнуть все апексные сессии, они скорее всего должны восстановиться в рамках пула сессий (не помню, как с mod_plsql), но всякая память и ресурсы связанные с ними освободятся. Тогда сможете проверить, помогло или нет и влияют ли здесь утечки. Можно какой-нибудь хитрый job написать, который бы давал сессиям таймаут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 17:04 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDom, А деградация идет только в апексовых сессиях, или в отдельных сессиях такая же картина? Если второе, то ИМХО апекс тут вообще не причем и с этим вопросом надо идти в ветку оракла. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 17:27 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Migelle, Если это утечки ресурсов, например PGA или TEMP, другие сессии очень даже могут быть причем. Самым простым способом утечки можно проверить - килянием. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 17:32 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
SvDev, Ну, про ТЕМР автор сам написал, что не помогает. PGA явно проверяли на исчерпание. У нас есть несколько проектов не на апексе, и коннекций сильно поменьше, веб-приложение общается с БД обменом CLOB-ами. Работает иногда годами без перезагрузки и деградации не наступает. Но все работает на 11.2, может 10.2 имеет в себе сей глюк. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 21:19 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Migelle, то что ТС писал по поводу TEMP, это не совсем то. Утекшую TEMP память в пуле сессий фиг освободишь без убийства сессии, во всяком случае я не знаю как. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. Тоже самое касается CACHE_LOBS. Настройки в ords типа jdbc.MaxConnectionReuseCount не просто так делают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2017, 10:04 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Коллеги, спасибо всем кто откликнулся. К сожалению текущую работу никто не отменял, а она немаленькая, и оперативно отвечать на предложения не получается. Поэтому отвечу всем сразу. Без LOBов нельзя - логика приложения, хранятся сканы документов. Нагрузку конечно можно попробовать воспроизвести, но для адекватных результатов надо бы и чтобы железо было одинаковое, а его нет. На счёт тестовых серверов. На самом деле тестовые сервера есть разные и на Linux Х_86_64 и на HP-UX Itanium (но железки с Itanium совсем чахлые). Ни на одном из них деградации работы с LOBами не замечено. Правда там и нагрузки нет. Есть идея запустить на самом загруженном сервере наш тест и посмотреть динамику. До сих пор мы этого не делали. Перейти на более новые версии Апекса пока не можем. 5 Апекс например стаёт только на Oracle 12, а вопрос миграции и лицензирования зависит от заказчика. Кроме того, это потребует некоторых ресурсов, человеческих и финансовых, а это опять зависит от заказчиков. Похожий вопрос задан и в общей ветке Oracle. Дисковая система не перегруженна, да и система в целом тоже. Из 48 ядер в среднем занято 40. Не думаю что виноват конкретно Апекс. Скорее всего это общая проблема LOB, а поскольку движок Апекса сам интенсивно работает с LOBами, то это сказывается и на нём. Однако нельзя исключать и того, что из-за интенсивной работы Апекса с LOBами общая нагрузка на LOBы сильно возрастает, и тогда проявляется проблема с LOBами. Да у нас mod_plsql. Регулярно перестартовываем Апачи, когда по разным причинам возростает нагрузка. Нагрузка сразу падает, но дело в том что деградация с течение времени увеличивается. В том числе и ночью когда Апекс нагрузки нет. Так что это врядли зависит от текущей нагрузки Апекса. На счёт темпов и undo. Проверяли так - создавали новое дефаултное ТП, а потом перестартовывали Апачи. Все Апексные сессии отваливались, а потом продолжались с новыми ТП. Никакого влияния на скрипт. Есть некие колебания времени работы скрипта в течении суток, но в целом идёт рост времени. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2017, 13:15 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDom, Ещё раз, спасибо всем кто откликнулся. Давайте не будем рассматривать работу с таблицами с LOBами, ограничимся нашим тестовым примером. В примере есть только временный LOB. Время выполнения этого скрипта монотонно растёт… Независимо от текущей мгновенной нагрузки на сервере. Насколько я понимаю, ничего, кроме процессора, памяти, хранимых процедур и темпа в нём не используется. Даже относительно ТЕМПа есть сомнения, т.к. темпLOB кэшируем и относительно невелик… Создаётся впечатление, что какие-то структуры управления памятью, выделяемой под ТемпLOBы, не чистятся в процессе работы сервера, монотонно наращивая свой объём из-за чего теряется скорость обработки… Как с этим бороться, непонятно… ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2017, 15:57 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
А если закрывать? Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2017, 16:10 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Так же попробуйте отказаться от Кэш, замедлит общий темп, но возможно на длительную работу не скажется. 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; / ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2017, 16:12 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2017, 16:13 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDom, «Так же попробуйте отказаться от Кэш, замедлит общий темп, но возможно на длительную работу не скажется.» Увы, время сразу возрастает примерно в 100 раз, что неприемлемо… Кстати, время без кэша растёт примерно в той же пропорции, что и с кэшем. Только по абсолютному значению раз в сто больше… “Сравнить состояние до и после через "AWR : Compare period reports" пробовали? Посмотреть на v$sgastat - если какие-то "структуры управления памятью" растут, может их поискать?” Идея вполне здравая, если бы не… Вот время работы скрипта за сутки выросло раза в полтора… Или за неделю – в десять раз… Что с чем сравнивать? «Сейчас» с «сутки назад» или «неделю назад»? БД-то реально рабочая, за сутки меняется всё… Хотя… Если сохранять СГАСТАТ , скажем раз в 10 минут, а потом вдумчиво смотреть на колебания циферок… Например, выстроить графики по каждому параметру за месяц… Ох, не знаю, не знаю… :-/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2017, 16:58 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDomДо сих пор мы этого не делали. сделайте. Это ваша обязанность. ПО для нагрузки есть. VDomно для адекватных результатов надо бы и чтобы железо было одинаковое, а его нет. не надо. Вы и так увидите динамику по памяти и производительности. VDomПерейти на более новые версии Апекса пока не можем. 5 Апекс например можете но не хотите. Апекс 4 от тройки отличается очень сильною. А вот 5 от 4 не сильно. Т.е. вам надо перейти на 4-ку. Либо жолго парить мозги вопросами с тройкой. VDomБез LOBов нельзя - логика приложения, хранятся сканы документов. т.е. вы одной фразой отписались и хотите варианты решения вашей проблемы? КОНКРЕТНЕЕ ЗАЧЕМ ЭТОТ ТИП ПОЛЯ НУЖЕН В ХРАНИМКЕ КРОМЕ ВЫГРУЗИТЬ НА КЛИЕНТА? VDomПохожий вопрос задан и в общей ветке Oracle. ссылку пожалуйста. Может мы по второму кругу обсуждам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2017, 21:50 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDomДавайте не будем рассматривать работу с таблицами с LOBами, ограничимся нашим тестовым примером. тогда это вопрос чисто ветки оракла. Дайте ссылку на то обсуждение. Апекс ни при чём вроде. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2017, 21:54 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Деградация носит кумулятивный характер, поэтому надо понять что может иметь кумулятивный характер, и может ли это быть связанно с операциями с LOB. С моей точки зрения это : 1) сегментация TEMP табличного пространства - замена табличного пространства TEMP на другое ничего не даёт поэтому этот фактор исключаем 2) рост swap памяти - проверка показала что свопа нет и он не растёт 3) переполнение каких то счётчиков, или семафоров - В HP-UX есть заклинание kcusage показывающее пороговые значения и текущие Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. Из приведённого только 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 но ничего конкретного. Складывается впечатление, что какие то структуры управляющие за управление памятью, с течением времени заполняются, в результате чего начинаются тормоза. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 10:38 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
В общей ветке это тема "Деградация производительности при работе с LOB" http://www.sql.ru/forum/1262261/degradaciya-proizvoditelnosti-pri-rabote-s-lobami Но в ветке Апекса намного больше предложений. С переходом на новые версии Апекс не всё так просто. Есть договор, в котором указано чего и какой версии должно быть. В любом случае это решает заказчик, а его этот вопрос меньше всего волнует. Кстати мы пробовали и 4 и 5 Апекс, так что мы готовы, но. Приложение и написано для работы со сканами разных документов, в этом его смысл. На самом деле мы вынесли из БД часть сканов (большую часть) в так называемый файловый архив. Но проблема с LOB никуда не делась и не ушла. Кроме того не забываем что у Апекса вся работа с файлами - загрузка/выгрузка, и собственно залмвка приложений всё идёт через таблицу WWV_FLOW_DATA с ITEM_VALUE CLOB. Учитывая интенсивное использование приложений на апексе так или иначе возрастает работа с LOB. Возможно достигается какой то порог, после чего начинаюся проблемы с LOB. Хотя да, в этом случае это проблема БД, но не без участия Апекс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 11:29 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDomВсе Апексные сессии отваливались, а потом продолжались с новыми ТП. т.е. прямое влияние апекса вы исключили, и всё говорит о том, что апекс ни при делах, проблема где-то на уровне базы в целом. Свидетельств косвенного влияния вы не продемонстрировали, апекс используется как прослойка и лишь в части функционала. Я так понимаю, свидетельств, что виновата загрузка или выгрузка нет, я бы, например, подозревал манипуляции с Persistent LOBs и, в том числе, другие опции. Похоже на какой-нибудь баг. VDomДавайте не будем рассматривать работу с таблицами с LOBами, ограничимся нашим тестовым примером. Если бы все было так просто, вы бы сами проблему легко воспроизвели, но тестовый пример проблемы роста времени выполнения, я так понимаю, не воспроизводит. Это значит, что виновато что-то что рядом, а рядом много чего, в SecureFiles and Large Objects Developer's Guide много красивых слов и опций, которые могут стрелять, например, только в комбинации, при наличии соответствующих багов на уровне оракла. Соответственно, я не вижу сейчас смысла смотреть проблему в привязке к апексу, с учетом, что нет свидетельств, которые явно указывали бы на апекс, или что апекс ограничивает как-то отладку проблемы, которая проявляется на уровне базы и имеет общий характер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 12:37 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDomНо в ветке Апекса намного больше предложений. но честнее было сразу сказать, что апекс ни при чём и дать ссылку). VDomПриложение и написано для работы со сканами разных документов, в этом его смысл. ну а апекс заточен на файловый архив. Есть разница? VDomКроме того не забываем что у Апекса вся работа с файлами - загрузка/выгрузка, и собственно залмвка приложений всё идёт через таблицу WWV_FLOW_DATA с ITEM_VALUE CLOB. не понял. Я сразу перебрасываю сканы в свою таблу. Никаких ваших ТАКИХ хранимок нету. Что я делаю не так? VDomУчитывая интенсивное использование приложений на апексе так или иначе возрастает работа с LOB. Мы про архитектуру вроде? Тогда огласите юз-кейс такой работы. Возможно вы апекс используете не по назначению....при баге в самой СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 13:08 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
SDev Да прямой связи с Апексом нет. Но косвенное очень даже может быть. Об этом я уже писал. То есть сам движок Апекса очень интенсивно работает с LOB. Поэтому Апекс скорее катализатор а не причина, причина гдето в БД. Мы тоже думаем что это может быть баг. Но реквесты, я создавать не могу. Да и даже если бы мог - Oracle 10 уже не поддерживается. Почему мы сосредоточились на тестовом примере. Во первых это объективный критерий по которому можно оценивать снижение производительности при работе с LOBами. По времени срабатывания скрипта можно понять что БД пора перегружать. Во вторых можно отбросить вопросы связанные с таблицами, их параметрами хранения и т.д. и т.п. И даже в этом упрощонном примере непонятны причины. У нас 10 БД поэтому SecureFiles нет. И всё таки какая то коссвенная связь между Апексом и производительностью работы с LOB есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 13:50 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDomПочему мы сосредоточились на тестовом примере. прогоните тесты на новых версиях БД и апекса. Установка апекс 30 минут и установка БД 2,5 часа на ноуте. С третьей версией апекса уже никто реально не работает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 13:56 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDomИ всё таки какая то коссвенная связь между Апексом и производительностью работы с LOB есть. Если бы у вас были какие-нибудь объективные данные для этого утверждения, демонстрация связи запросами с проблемного сервера не было бы такой большой проблемой. Легко обвинить часть приложения, о которой не всё знаешь, но тем не менее это не конструктивный подход. Апекс действительно много работает с CLOB/BLOB и на уровне item в том числе, но и вы сами наверняка тоже с большими объемами LOB работаете. Часть с апекс отлажена большим числом людей с разными архитектурами приложений и pl/sql, часть с вашим приложением ограничена только вашей архитекторой с вашим кодом и отлажена хуже, чем apex сотрудниками oracle во всевозможных ситуациях. Тестовый пример никак не связан с апекс, поэтому, как минимум, я предлагаю вам собрать больше данных в другом разделе, чтобы появился хоть какой-то смысл смотреть конкретно что-то в привязке к апекс. Прочего рода совета намного рациональнее обсуждать в разделе oracle. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 14:44 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Petro123 Дело в том что на всех наших тестовых серверах, и на IA64 и на x86_64, время работы нашего тестового скрипта не растёт. Так что нет смысла пробовать на других версиях БД или Апекса. На некоторых тестовых серверах даже работы выполняются, но нагрузка не соизмеримая. Видимо дело всё таки в нагрузке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 17:44 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDomДело в том что на всех наших тестовых серверах, и на IA64 и на x86_64, время работы нашего тестового скрипта не растёт. странно у вас с логикой. Это ваше: авторПромоделировать ситуацию не удаётся, так как на тестовых серверах не удаётся организовать адекватную нагрузку. говорит что тестовой площадки нормальой у вас НЕТ. Вы не умеете её готовить. А вы пишите что время скрипта не растёт. Обычна лень. Уж извините. Поэтому у вас даже у себя....без заказчика нет четвёрки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 20:22 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDom, про бизнес логику и зачем хранимка вы тоже не ответили. Поэтому удачи! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 20:23 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Petro123 C логикой у нас всё нормально. Тестовых серверов у нас 4. На одном из них заказчик учится. Загрузка его не соизмерима с промом - там миллионы коннектов в сутки. На остальных нагрузки нет вовсе. До последнего времени мы мониторили скорость срабатывания тестового скрипта только на проме. В качестве критерия мы используем время работы тестового скрипта. Так вот оно ни на одном тестовом сервере не растёт. Для адекватной ситуации надо на одном из тестов создать соизмеримую с промом нагрузку, а это не реально. Нам просто некуда записать такую нагрузку даже за сутки, требуется хотя бы несколько дней. По поводу приложения. У нас штук 40 приложений на Апексе, и даже затрудняюсь сказать сколько разных других программ. Несколько Апексных приложений специально разработаны для работы с документами, в том числе и сканами документов. Чтобы как то разрулить ситуацию с LOBами (а первой возникла проблема с местом и временем логического экспорта), был разработан так называемый файловый архив в который выгрузили большую часть имеджей. За счёт этого сильно сократился размер БД и сейчас он занимает всего 10ТБ. Однако выявилась другая проблема которая была и раньше, но которая не диагностировалась, связанная с лобами - снижение скорости работы с LOB в течении 2-3 недель. Эта проблема выявилась при использовании программы загрузки/выгрузки документов в LOB. Скорость её работы падала в сотни раз. Разбор этой ситуации и выявил проблему которой посвящено данное обсуждение. Кроме того у нас периодически возникает ситуация, когда приложения разработанные на Апекс устанавливается очень долго. В нормальной ситуации это пара минут, а потом время установки возрастает до часов. Причины этого нам были не понятны. После выявления проблемы деградации производительности с LOB стало понятно что это одна и та же проблема. Дело в том что движок Апекса очень интенсивно работает с LOB. Например все загрузки/выгрузки файлов выполняются через таблицу www_flow_data с LOB полем. Это относится и к загрузке Апексных приложений. Поэтому это обсуждение есть и в Апексной ветке и в основной ветке Oracle. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2017, 11:56 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDomДля адекватной ситуации надо на одном из тестов создать соизмеримую с промом нагрузку, а это не реально. У меня впечатление, что вы всех убеждаете о невозможности создать нагрузочный тест. Каждый раз у вас новый аргумент. Вот, на второй странице новый: VDomНам просто некуда записать такую нагрузку даже за сутки, требуется хотя бы несколько дней. - нагрузку не записывают. Нагрузку создают. - результаты нагрузки в виде БЛОБ закачанных сканов можно удалять тем же JOB'ом. ....... Далее вы в 10 раз мешаете все проблемы в кучу так, что читать сложно. Ещё раз: 1. Тестовая площадка для нагрузочного тестирования по ГОСТ 2. Архитектура ИС как рекомендует Оракл для версии 4 и 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2017, 12:20 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Petro123Я сразу перебрасываю сканы в свою таблу. Никаких ваших ТАКИХ хранимок нету. Что я делаю не так? Если кто не в курсе, работа с файлами в Апекс (я имею ввиду нормальный не эмбедед Апекс 3) в общих чертах выглядит так : В интерфейсе создаётся элемент File brauser из которого файл попадает в apex_application_files, из которого потом можно переместить его туда куда нужно. Это стандартная процедура есть примеры и т.д. На самом деле apex_application_files это вьюшка на wwv_flow_file_objects$. В конце манипуляции с файлом надо только не забывать чистить apex_application_files Код: plsql 1. Иначе со временем вы можете "внезапно" выяснить что табличка wwv_flow_file_objects$ сильно выросла и съела всё свободное место в ТП. Подчёркиваю вся вся работа с файлами (и исходниками собственно приложений Апекса) проходит через wwv_flow_file_objects$. Сделайте например импорт Апекс приложения, потом посмотрите, что оно появилось в репозитрории Апекс. Затем посмотрите wwv_flow_file_objects$ и вы увидите что ваше приложение в ней - это и есть репозиторий. Короче все файлы в Апексе проходят через неё. Возможно в других версиях Апекс что то изменилось, но это вряд ли. Кто сомневается - проверьте её размер, после инсталляции Апекса и например, через год работы системы. Заодно посмотрите что в ней, и узнаете много интересного. И это не единственная таблица Апекса с LOB. Весь движок Апекса очень бурно работает с LOB полями. Если вы пока не этого не заметили, значит у вас не сильно активно пользуются приложением. Именно поэтому мы связываем деградацию производительности при работе с LOB и АПЕКС. То есть проблема возникает только на интенсивно работающих с Апекс приложениями системах. Я не говорю что виноват Апекс, проблема в БД но проблема проявляется под влиянием Апекса. Но что же на самом деле происходит непонятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2017, 12:49 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDomЕсли кто не в курсе я в курсе VDomИначе со временем вы можете "внезапно" выяснить есть запрос, который показывает это конкретно. И нет никакой "внезапно". Дальше опять бла бла бла. Вы не знали что есть запрос на чистку при загрузке БЛОБ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2017, 12:57 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
повторяю вопрос. Что я делаю не так? Код: sql 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2017, 13:07 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDomИменно поэтому мы связываем деградацию производительности при работе с LOB и АПЕКС. Начиная с 5.0 апекс ушел от этого хранилища, вместо apex_application_files используется apex_application_temp_files, который чистится сам (хотя кое какие проблемки там еще остались, если выбирать сразу конечную таблицу в качестве хранилиша), более того использование старого хранилища desupported в 5.1. Начиная с apex 4.2 (фактичиски с 4.1.1, если патчем) в связке с ords, если вам не нравится как в этом плане устроен mod_plsql, можно использовать restful сервисы для загрузки файлов (пример есть в документации) без промежуточных таблиц. Но опять же, каких либо данных, что именно с этим связаны ваши проблемы не представлено. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2017, 13:25 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Petro123повторяю вопрос. Что я делаю не так? Немного не по теме. В версиях до 5.0 этого недостаточно, этот код оставляет мусор после себя. Проблема не сколько в апекс, а во многом на уровне параметров PlsqlDocumentTablename mod_plsql и apex.docTable в ords и том, как они работают. Файл грузится в служебную таблицу, код очистки выполняется гораздо позже. Если посередине есть валидация или сработает какая-нибудь другая ошибка файл остаётся в базе. В случае с ords напрашивается интеграция с restful, чтобы файлы грузились сразу в конечную таблицу и декларативно через какой-нибудь системный rest сервис, но пока декларативного нет. VDomКроме того не забываем что у Апекса вся работа с файлами - загрузка/выгрузка, и собственно залмвка приложений всё идёт через таблицу WWV_FLOW_DATA с ITEM_VALUE CLOB. Мне неизвестно, чтобы WWV_FLOW_DATA был как-то связан с файлами. Могу ошибаться, но насколько мне известно: - В старых версиях все items хранились как clob, чтобы обойти ограничения в 4000. - В новых версиях хранится в 2-х столбцах varchar2 и clob, в clob помещается если между 4000 и 32767. - Если включена опция 12c с 32767 в varchar2 в таблицах - вполне вероятно как clob вообще не хранится, не проверял. - Если бы у вас с этой таблицей была бы проблема, врят ли вы бы жаловались на заливку приложений, все приложения повисли бы напрочь. - Очень вероятно, что 11g или 12c решают проблему в топике. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2017, 13:16 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
+ могу ошибаться, но, мне кажется, в старых версиях мастера делали Item Source: Only when current value in session state is null где-то по умолчанию при создании форм (может быть я что-то путаю). Сейчас при создании форм используется Item Source: Always, replacing any existing value in session state, если источник database column и если приложение не в старом compability mode, поменять эту опцию на предыдущую уже нельзя. Среди прочих отличий этих опций: одна из них используется совместно с persisted session state, другая c in-memory session state (и не хранится в таблице). Врят ли эти изменения связаны непосредственно с производительностью, но на производительность, вероятно, тоже какое-то влияние оказывают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2017, 13:42 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
SvDev, очень много допущений и гаданий на кофейной гуще. Я выше писал, что на данной ветке уже разбирали этот мусор и приводился запрос который показывает этот мусор. Я запрос у себя запускал на продакшене и никакого мусора нету. Могу поискать тот запрос. А то как в анекдоте: "видишь суслика?". ... Про транзакцию при скачке, разумеется у меня есть try в коде чтобы процесс не прервался и завершился. Нет проблем. Проблемы у ТС т.к. он решает по админски, а надо решать по программистски (заменяя кусками). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2017, 14:56 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Petro123, Это потому что ты валидацию не делаешь и ограничение на размер заливаемого файла (очень частое требование) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2017, 15:11 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
SvDevPetro123, Это потому что ты валидацию не делаешь и ограничение на размер заливаемого файла (очень частое требование) Это типа предложение что можно сделать в хранимке? Пусть автор конкретнее скажет use-case или Варианты Использования(ВИ). Что именно он валидирует при функционале: "Закачать файл на сервере". Тогда можно подумать о решениях. Их много всяких. Причём на том же JS вообще ПЕРЕД закачкой. Или сделать тест на двое суток, где отменять закачку по валидации на 100000 блобов. Но не так что тему мусолить 3 страницы и ничего не делать. ... У меня система в продакшене успешно 3 года. Он тут один с таким вопросом тоже 3 года. Сразу напрашивается вывод, что дело не в апексе, а топик стартере. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2017, 12:17 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
кстати, запрос с показом мусора при работе с download\upload никто не привёл. А он тут был в каком то топике про "тормоза". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2017, 12:22 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Petro123, Вопроса про мусор не было . Тебе надо - создай тему, лень объяснять. Petro123Он тут один с таким вопросом тоже 3 года. Сразу напрашивается вывод, Зато подобных шаблонных ответов по всему разделу большая куча... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2017, 12:36 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
SvDevВопроса про мусор не было . Тебе надо - создай тему, лень объяснять. твоё: авторВ версиях до 5.0 этого недостаточно, этот код оставляет мусор после себя. SvDevЗато подобных шаблонных ответов по всему разделу большая куча... это не удивительно. Конструктор апекс с низким порогом вхождения (мало кода и много вопросов). Удачи автору! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2017, 13:23 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
SvDev, вообще, сегодня наверно ты не с той ноги встал. На протяжении топика ты говорил что данных мало чтобы судить о связи апекса с проблемой ТС. Появились какие то новые данные? Пусть ТС идёт делать тесты. А то флуда много пошло. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2017, 13:30 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Petro123, Вопрос с файлами просто элементарно проверяется, делается любая валидация, которая срабатывает при загрузке, в разделе validations и загружается любой файл. Дальше в wwv_flow_files по имени файла найти можно. Обойти можно конечно, но лучше не в этой теме. Про тесты согласен. Про то, что каких-то вопросов не было не аргумент. Многие вопросы, например, обсуждаются на otn форуме и здесь не освещены. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2017, 13:47 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
SvDevВопрос с файлами просто элементарно проверяется да. Согласен. Пусть ТС тестит. Я тоже ленивый)). Шутка. SvDevПро то, что каких-то вопросов не было не аргумент. Многие вопросы, например, обсуждаются на otn форуме и здесь не освещены. А такой аргумент? В катастрофах и НЕработоспособности, есть правило от инженеров: "самая простая причина обычно самая правильная". Звучит как то так, но пословица говорит, что бОлее вероятно что у ТС - простейшая причина. Как то: Версия апекс тройка или лишние хранимки по архитектуре. Это не я говорю. Это инженеры)). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2017, 14:03 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Petro123, Хранимки чаще всего не лишние, вместо них можно воткнуть слова: oracle database - 10-ка, а так очень даже) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2017, 14:19 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
SvDev, Я работы на тройке видел кусками. Сам с 4-ки начал. Те куски что видел говорили о том, что там были в порядке вещей велосипеды с ручным перебросом айтемсов на сервер. Или частое http.print( Я же за декларативную разработку начиная с 4-ки). Но гадать конечно не будем. Про 10 ку разумеется. При смене версии платформы автоматом и база сменится. Выше писал, что установка базы 2,5 часа. Противопаказаний нет. Только желание. imho Удачи! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2017, 14:26 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Petro123, И стоимость) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2017, 14:28 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
SvDev, XE бесплатная ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2017, 16:52 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Petro123, Если 10 Тб базу с 48 ядрами переведёшь на XE, я думаю, Нобелевскую получишь) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2017, 17:19 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
SvDev, Дык мы о тестовой площадке всё. О ней родимой. Для нее только желание. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2017, 17:37 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Petro123, Для нормальной тестовой площадки XE не хватит, для этого скорее всего можно бесплатно EE использовать, если хватит Oracle Technology Network License Agreement для данного случая, вроде должно хватить. Но тут надо сначала воспроизвести проблему, иначе смена версии БД или чего-то еще на тесте ничего не покажет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2017, 18:14 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Petro123, Ошибаетесь уважаемый, сначала в реал тестинге записывают (ну или если хотите сохраняют) а потом проигрывают (или если угодно создают) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2017, 16:14 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDom, Как с поиском зависимостей, какие-то конкретные данные статистические есть ? Например, apex_workspace_activity_log - можно понаблюдать количество запросов к определенным страницам, содержащий определенный функционал (exists apex_application_page_items / apex_application_page_proc и др) Проверить корелляцию запросов к страницам не содержащий этот функционал и т.д., таким образом сужать круг... При работе с такими проблемами это не всегда надежный способ, проблема всегда может оказаться в каком-то другом месте, но если она, например, косвенно связана с апексом, то есть вероятность найти какой-нибудь неожиданный способ её исправить. + У вас есть вариант обновиться до апекс 4.2 (в котором было много оптимизаций, например под RAC (apxpart.sql) и в таблице wwv_flow_data в том числе ) и ords 2.0.10 с app server (не знаю как поведёт себя ваша система на нём, но зато вы сможете использовать RESTful ). Это имеет смысл, если вы связываете проблему с wwv_flow_file_objects$ и wwv_flow_data, можно сделать замеры, как зависит нарастание проблемы от времени и разного рода нагрузки, и сделать тесты как изменилось нарастание после переезда. Заодно будут пересозданы апексные таблицы в новую схему (кроме wwv_flow_file_objects$) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2017, 18:42 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Добавлю, можно посмотреть как изменилась таблица wwv_flow_data 3.1.2 Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 4.2.6 Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. Соотношение clob ко всем остальным не clob, очень низкое, например, оно может быть 0.0001 % (на сервере, что я проверял, нагрузка небольшая, зато приложений много). И те в новых версиях хранятся как out of line, т.е. не мешают ничем проверить Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Это я всё веду к тому, что упомянутых узких архитектурных мест с LOB в современных версиях апекса нет. И что, и в 3-тьей версии, не увидел каких-либо подтверждений участия апекс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2017, 18:48 |
|
||
|
|

start [/forum/topic.php?all=1&fid=50&tid=1874320]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
175ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
72ms |
get tp. blocked users: |
2ms |
| others: | 13ms |
| total: | 307ms |

| 0 / 0 |
