|
|
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Здавствуйте! Сегодня получил массу сообщений ORA-04030. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. init.ora Код: 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. ОС: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Не знаю, какие параметры ещё нужно предоставить. Код: 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. 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. Количество подключений в момент траблов: порядка 1200. Уважаемые знатоки, какие параметры менять, чтобы увеличить число возможных подключений? Как узнать, сколько _реально_ памяти занимают сессии (ps выдаёт заведомо большие значения, учитывая объёмы shared memory процессов по несколько раз)? Добавить оперативную память возможности нет. Заранее благодарен за помощь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2018, 11:23 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Хливкие Шорьки, Как обычно: или увеличивать доступное PGA, или уменьшать потребление со стороны ПО. Посмотрите потребление памяти сессиями в v$sesstat, statistic# 36. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2018, 14:37 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Чувак, если ты ничего не утаил, то для БД сервер у тебя лопает 17+1.4 +/- 3 G из 64 гиг Т.е. либо у тебя есть какие-то процессы (не относящиеся к Oracle), выкушиваюшие память, либо это server-process-ы оракловых сессий, например, использующих PL/SQL таблицы/переменный и забывающие освобождать память. Товарищи говорят, что предел -- 4GB, я наблюдал 16GB, но это SPARC Solaris Можно искать по ps -- все что больше 20 гиг -- твои клиенты Можно тупо пресекать (на тестовой уж точно) -- event 10261 (в твоей версии) Ну, а еще как подсказали (совершенно по-дурацки, но тем не менее) смотреть текущие статистики сессий А лучше уж и статистики процессов (V$PROCESS) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2018, 16:04 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Хливкие Шорьки, Код: plsql 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2018, 16:12 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Вячеслав ЛюбомудровЧувак, если ты ничего не утаил, то для БД сервер у тебя лопает 17+1.4 +/- 3 G из 64 гиг Т.е. либо у тебя есть какие-то процессы (не относящиеся к Oracle), выкушиваюшие память, либо это server-process-ы оракловых сессий, например, использующих PL/SQL таблицы/переменный и забывающие освобождать память. Не вижу смысла что-то утаивать, это может препятствовать получению ответа на вопрос. Процессов, не относящихся к Oracle, нет, не считая системных. Кстати, после перезапуска экземпляра освободилось 26 Гигабайт оперативной памяти; не подтверждает ли это версию о не освобождающих память сессиях? Вячеслав ЛюбомудровМожно тупо пресекать (на тестовой уж точно) -- event 10261 (в твоей версии) Можно подробнее? Где возникает этот event и как его пресекать? Вдогонку ещё вопрос: можно ли сэкономить PGA, перейдя с dedicated server на shared? Если да, какие могут быть подводные камни (например, как при этом будут работать dblinks от/к этой БД с учётом большого tps, не будет ли заморочек при switchover)? Надеюсь, я не слишком многого хочу от уважаемых отвечающих. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2018, 04:29 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Про event 10261 нашёл, в моём случае не походит. :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2018, 07:12 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2018, 10:42 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Зайди в OEM-Server-Memory Advisors, посмотри потребление PGA и максимальное PGA за все время работы. Посмотри что у тебя с файлом подкачки, недавно было, что база улетела нафиг в даун оттого что файл подкачки был жестко фиксирован. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2018, 11:14 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
processes обычно сопровождается параметром sessions, который больше его раза в 1.1 примерно То есть на 1500 процессов у тебя должно быть 1650 сессий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2018, 11:19 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Зачем задавать жестко параметры SGA, задай sga_target, pga_aggregate_target, остальные составляющие убери, пусть внутри них сам распределяет. (Тут меня конечно могут попинать, но я считаю тяжело это подобрать самому) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2018, 11:36 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
nata44845Зачем задавать жестко параметры SGA, задай sga_target, pga_aggregate_target, остальные составляющие убери, пусть внутри них сам распределяет. (Тут меня конечно могут попинать, но я считаю тяжело это подобрать самому) А кто же их за Вас подберёт? Неужели срочно Ларри звонить? А он кстати уже подумал о Вас вот - https://cloud.oracle.com/atp Только вас там больше не надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2018, 12:08 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Если сложно подобрать, то и не надо. Все таргеты и максы в ноль, кроме memory_max_target и memory_target читаем вот это и будет счастье https://docs.oracle.com/cd/B28359_01/server.111/b28310/memory003.htm#ADMIN11011 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2018, 16:06 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2018, 16:10 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
A K, Если я правильно помню, у оракла есть особенность, когда задана memory_target он делит ее в соотношении 60/40. Поэтому желательно задавать sga_target, чтобы показать, что sga не должна быть меньше этого значения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2018, 05:58 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Да какие-бы он не задавал параметры, против выжирания памяти какими-нибудь PL/SQL-таблицами до 12c был только вариант event 10261 . Да и все приводимые запросы мало чем помогут в анализе древней ситуации А вот почему ОС не смогла отдать столько памяти, тут другой вопрос. Как минимум надо настроить тот-же sar (в солярке обычно достаточно просто раскомментировать соответствующие строки в crontab от sys ). Можно периодически сбрасывать информацию о наиболее жрущих процессах в ОС ( ps -eo vsz,user,args | sort -n | tail -5 ). Не забыть только время указывать :-). Можно также периодически запрашивать структуру памяти, как показал Scott Tiger , если не хватает того же sar (в обоих случаях тот же ненастроенный ZFS ARC съест все неиспользуемую память, так что свободной памяти практически не будет). Конечно, если все это случается нечасто, надо предусмотреть какую-либо ротацию всех этих отчетов А есть вариант, что это попытка превышения oracle process memory limit (ни в коей мере ни соотносится с PGA_AGGREGETE_TARGET). На Solaris SPARC я наблюдал до 16 GB, хотя встречалось утверждение, что максимум -- это 4GB. Это именно память в куче. Т.е. если мы видим в ps процесс с vsz больше чем SGA плюс несколько гигов -- как правило, это уже наш поциент. В этом тоже может помочь периодический сбор информации о процессах ОС PS. можно заставить сбрасывать трассу, чтоб посмотреть где и когда это случилось https://blogs.oracle.com/db/ora-4030-troubleshooting To setup tracing to trap the ORA-4030, on the server use the following in SQLPlus: alter system set events '4030 trace name heapdump level 536870917;name errorstack level 3'; Once the error reoccurs with the event set, you can turn off tracing using the following command in SQLPlus: alter system set events '4030 trace name context off; name context off'; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2018, 09:47 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Накаркала, у меня такое же, причем в основном жрет oravssv, цитирую Дмитрия БобровскогоЕсли резервирование выполняется без использования VSS, лучше отключить или вообще удалить эти службы Oracle <SID> VSS Writer Service. Т.к. они потребляют ресурсы. А так же возможна утечка памяти (unpublished Bug:9063341) — Instance Crash Or ORA-04030 Errors When Pagefile Is Full [ID 1358570.1] или Bug 10209909 : ORAVSSW PROCESS CONSUME ALL MEMORY Посмотрела другие сервера, там служба вручную стоит на запуск По идее если пользуемся RMAN можно отключить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2018, 06:07 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
>Если я правильно помню, у оракла есть особенность, когда задана memory_target он делит ее в соотношении 60/40. Откуда такая информация ? На самом деле такое поведение будет зависеть от объемов оперативки для БД и от характера работы с ней. Если у вас БД имеет пару гик, то приблизительно так и будет. Если десятки гик, то скорее всего PGA останется в раионе 2-4 гб, остальное уйдет на SGA. >Поэтому желательно задавать sga_target, чтобы показать, что sga не должна быть меньше этого значения. Я такой рекомендации не встречал. Скорее наоборот. При memory_target оракл на основе своих метрик сам расчитает сколько ему на что нужно. Ну а вы смотрите сами. Если есть понимание, почему вам нужно самостоятельно управлять размерами, переходите на раздельное управление PGA И SGA. Ну а если разумно - то я не вижу причин не доверять Ораклу, там где это возможно. Из своей парктики - SGA выше макса подкрутить к сожалению нельзя, не перегружая БД. PGA, через таргет можно увеличивать динамически. Там где крайне не желательна перегрузка БД, и где в зависимости от ситуации нужна манипуляция PGA - там лучше переходить на раздельное управление. В остальных случаях - можно вполне довериться ораклу. Ну, еще, разве что у вас какие-то редкие настройки под бизнес - тогда вообще лучше от любого автомата отказаться и все области настраивать вручную ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2018, 14:25 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Понятно, что рельный объем на уровне физики и объем указаный в параметрах БД не совпадают и идет в сторону увеличения на уровне физики. На эту тему есть масса публикаций. Расчитывали и тот и другой объем вполоть до байт. Что бы не нарываться на ошибки с памятью, я , например - на Оракл выделяю на несколько гик меньеш чем у меня оперативы (при условии, что у меня на серваке ничего не крутиться окромя БД). Как, правило, этого воплне хватает что бы не нарваться на подобную ошибку, при условии что сервак исправен конечно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2018, 14:31 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
A K, Видимо отсюда SGA_TARGET, SGA_MAX_SIZE and PGA_AGGREGATE_TARGET are set to 0, 60% of memory mentioned in MEMORY_TARGET is allocated to SGA and rest 40% is kept for PGA. Ссылка А вообще автор пропал, теперь более чем уверена, что у него дело не в памяти, а в Oracle VSS, но память все равно причесать бы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2018, 17:52 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2018, 17:53 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Народ, при чем здесь VSS? У ТС - Solaris Volume Shadow Copy Service (VSS) — это инфраструктуры на платформе Windows Server, которая позволяет приложениям создавать теневые копии (shadow copies). Теневая копия — это согласованный! снимок данных на четко определенный момент времени. Короче говоря эта инфраструктура позволяет делать согласованные! снимки отдельных файлов или всего тома (диска) без остановки работы. И это обеспечивается ядром ОС Windows. Сервис Oracle <SID> VSS Writer Service — это сервис Oracle, который обеспечивает координацию между отдельным экземпляром Oracle (на каждый экземпляр создается свой сервис) и VSS инфраструктурой. Это позволяет, используя ПО сторонних производителей, выполнять «горячее» резервное копирование и восстановление. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2018, 18:07 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Vadim Lejnin, Пардон, упустила из виду Значит косяк с VSS только у меня был. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2018, 18:10 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
> http://osamamustafa.blogspot.com/2012/11/sgamaxsize-sgatarget-memorytarget.html ну это частное мнение хозяина блога (который не разобрался как следует в очень интересной тематике). Хотелось бы правило 60 на 40 увидеть в официальной документации (думал на винде такая ерундовина - у меня БД стоят на линуксе). Сегодня специально искал, но не нашел и не найду :). Потому, что: https://blog.dbi-services.com/oracle-automatic-memory-management-monitoring-the-memory-usage/ Внимательно прочитайте этот блог. Вам все станет ясно как Оракл распределяет на автомате память и необычность поведения значения параметров, которые ранее были предельно понятны. А теперь практика: У меня на одной из БД, где 12Гб оперативы ситуация следующая (memory_max_target = 12G и memory_target = 12G), далее select * from V$MEMORY_DYNAMIC_COMPONENTS 5 SGA Target 7730102272 7730102272 7730102272 0 0 STATIC 4194304 15 PGA Target 5154799616 5154799616 5154799616 0 0 STATIC 4194304 Похоже правда на 60 и 40, но :) А теперь посмотрим что и сколько реально занимает: select name , value from v$pgastat where name = 'total PGA allocated' 1 total PGA allocated 297175040 Уже и никакие не 40 процентов :) а теперь делаем вот это - show sga Total System Global Area 7695769600 bytes Fixed Size 2323360 bytes Variable Size 1249905760 bytes Database Buffers 6438256640 bytes Redo Buffers 5283840 bytes Как же нам это понимать? : variable size = current SGA + what could be stolen to the PGA .ndeed, it considers that the variable size might grow up to 1249905760 bytes, leading to a PGA reduction to 0! The information “Total System Global Area” must be interpreted with care! Ну вот как то так. Просто нужно понимать что таргеты - это одно, а реальный объем это другое. Еще раз обратите внимание какой реальный расклад для PGA на 12Гб мемори_таргета: select name , value from v$pgastat 1 aggregate PGA target parameter 5154799616 5 total PGA allocated 360601600 6 maximum PGA allocated 411419648 То есть 5 гб (40 процентов) он как бы может отожрать, но в реальности отжирает только 360М Скорее всего, при нормальном раскладе в реальной жизни он вряд ли отожрет больше 1Гб - если внутренние таргет адвайсеры скажут это сделать. Ну и соответственно SGA не обязан сразу выжирать большую часть общей памяти, а только когда БД это станет нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2018, 20:21 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
В общем не заморачивайтесь этим и если нет к тому, серьезных оснований - устанавливайте память на автомат! Еще раз на тесте можете прогнать и убедиться, что в реальности никакого 40 на 60 распределения памяти не существует. У Oracle механизм распределения памяти на автомате - достаточно продвинутая штука, что бы делать подобные глупости в реале. :):) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2018, 20:39 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
A K> http://osamamustafa.blogspot.com/2012/11/sgamaxsize-sgatarget-memorytarget.html ну это частное мнение хозяина блога (который не разобрался как следует в очень интересной тематике). Хотелось бы правило 60 на 40 увидеть в официальной документации (думал на винде такая ерундовина - у меня БД стоят на линуксе). Сегодня специально искал, но не нашел и не найду :). Automatic Memory Management (AMM) SGA and PGA Management in 11g and Above (Doc ID 1392549.1) Automatic Memory Management (AMM) on 11g & 12c (Doc ID 443746.1) A K https://blog.dbi-services.com/oracle-automatic-memory-management-monitoring-the-memory-usage/ Внимательно прочитайте этот блог. Вам все станет ясно как Оракл распределяет на автомате память и необычность поведения значения параметров, которые ранее были предельно понятны.Тут только ясно, что автор неправильно интерпретирует “variable size = current SGA + what could be stolen to the PGA” У него все четко по цифрам: Total System Global Area = memory_target = Fixed Size + Redo Buffers + Database Buffers + Variable Size Где Variable Size = Shared pool + Large pool + Other pools (Java, Streams, Result cache) + Свободное место, которое пока отдано под PGA (workareas) A KА теперь практика: У меня на одной из БД, где 12Гб оперативы ситуация следующая (memory_max_target = 12G и memory_target = 12G), далее select * from V$MEMORY_DYNAMIC_COMPONENTS 5 SGA Target 7730102272 7730102272 7730102272 0 0 STATIC 4194304 15 PGA Target 5154799616 5154799616 5154799616 0 0 STATIC 4194304 Похоже правда на 60 и 40, но :) А теперь посмотрим что и сколько реально занимает: select name , value from v$pgastat where name = 'total PGA allocated' 1 total PGA allocated 297175040 Уже и никакие не 40 процентов :) а теперь делаем вот это - show sga Total System Global Area 7695769600 bytes Fixed Size 2323360 bytes Variable Size 1249905760 bytes Database Buffers 6438256640 bytes Redo Buffers 5283840 bytes Как же нам это понимать? : variable size = current SGA + what could be stolen to the PGA .ndeed, it considers that the variable size might grow up to 1249905760 bytes, leading to a PGA reduction to 0! The information “Total System Global Area” must be interpreted with care! Ну вот как то так. Просто нужно понимать что таргеты - это одно, а реальный объем это другое. Еще раз обратите внимание какой реальный расклад для PGA на 12Гб мемори_таргета: select name , value from v$pgastat 1 aggregate PGA target parameter 5154799616 5 total PGA allocated 360601600 6 maximum PGA allocated 411419648 То есть 5 гб (40 процентов) он как бы может отожрать, но в реальности отжирает только 360М Скорее всего, при нормальном раскладе в реальной жизни он вряд ли отожрет больше 1Гб - если внутренние таргет адвайсеры скажут это сделать. Ну и соответственно SGA не обязан сразу выжирать большую часть общей памяти, а только когда БД это станет нужно.Что-то никак не бъется Total System Global Area с memory_target Очень похоже, что это вывод с другой БД, без AMM И тогда 1249905760 (а это ~1 Гиг, а не 12 ) -- это размер Shared pool + Large pool + Other pools (Java, Streams, Result cache) безо всякого PGA К тому же стоит различать PGA workareas, которые рулятся PGA_AGGREGATE_TARGET / MEMORY_TARGET и которые используются для операций сортировки/хэширования и Private SQL Area (которые тоже являются частью PGA процесса), которые не обращают никакого внимания на эти установки. К тому же, у автора AMM вообще не используется (да и смысл использования его под линуксом/солярисом вызывает большие сомнения -- в линуксе это отказ от HugePages, в солярке -- использование DISM, и в свою очередь резервирование свопа) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2018, 04:47 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Большое спасибо за ссылку на доку - к сожалению все на металинке. Сейчас у меня к нему доступа нет. Так что смог только урывками по инету прочитать. Но, насколько я понял из отрывков - The policy is to give 60% to the SGA and 40% to the PGA at startup. То есть, параметр динамичный. Эти значения плавающие. Что, кстати, автор блога и хочет сказать и что на моей 12ГБ БД и видно. (На самом деле я свой комент компилировал с автором блога. У него действительно в примере стоит 1Гб общей памяти, у меня на БД 12ГБ. Поэтому тут как бы все смешалось. Сорри.) Вячеслав, смотрите, у меня 12Гб БД (LINUX RH 6) стоит AMM, паратеры следующие (снял замер только что): select name, value, display_value from v$parameter v where v.name like '%target%' sga_target 0 0 memory_target 12884901888 12G memory_max_target 12884901888 12G pga_aggregate_target 0 0 То есть на бд жестко задан режим AMM Теперь: show sga Total System Global Area 7695769600 bytes Fixed Size 2323360 bytes Variable Size 1182796896 bytes Database Buffers 6505365504 bytes Redo Buffers 5283840 bytes а теперь самое интересное: select name , value from v$pgastat where name = 'aggregate PGA target parameter' aggregate PGA target parameter 5154799616 И как бы да - создается впечатление, что имеет место быть соотношение 40 на 60, но: select name , value from v$pgastat total PGA allocated 344553472 maximum PGA allocated 500199424 total freeable PGA memory 44236800 PGA memory freed back to OS 9774432256 То есть реально PGA занимает 328Мб. А если по сути, я хотел донести: Никакого жесткого соотношения 40 на 60 не существует. Как в примере на моей БД - реальный объем PGA = 328МБ. Безусловно, если интенсивность возрастет, динамически возрастет и PGA. Но, если будет нужно больше памяти для SGA - соответственно вырастет и он. Насчет использованием под линуксом - Есть несколько баз с AMM (6-12 Гб оперативы). Работает сносно уже несколько лет. Главное как я писал выше, за границы физической памяти не выходить, когда мемори_таргеты выставляешь (отсавляю приблизительно 2-4 гб) Ну, а есть очень большие (до 100гб оперативы), тоже под линуксом - там действительно PGA и SGA настроены раздельно (так сложилось исторически). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2018, 12:32 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
A KНикакого жесткого соотношения 40 на 60 не существует. Как в примере на моей БД - реальный объем PGA = 328МБ. Безусловно, если интенсивность возрастет, динамически возрастет и PGA. Но, если будет нужно больше памяти для SGA - соответственно вырастет и он.Про жесткое соотношение и реальный объем это ты сам придумал Есть конкретный алгоритм -- если задано только MEMORY_TARGET, то НАЧАЛЬНОЕ соотношение будет 60/40 Естественно, в процессе работы оно будет меняться в зависимости от нагрузки (более того -- будут меняться размеры компонентов внутри SGA) -- на то это и автоматическое управление памятью. Вот тебе еще и на Бурлесона ссылочка , он, как обычно перепощивает металинковские ноты своими словами Дальше, про PGA -- можно вспомнить, что PGA_AGGREGATE_TARGET это желаемое ограничение для всех workarea всех процессов. По умолчанию, размер одной workarea (область для сортировки/хэширования) будет не превышать 5% от PGA_AGGREGATE_TARGET для обычных запросов и 20% для параллельных. Это насчет разницы между TARGET и ALLOCATED И вот еще -- можно ведь выставить нижние пределы (например DB_CACHE_SIZE, SHARED_POOL_SIZE) -- вот есть подозрение, что при этом неявно выставляется нижний предел SGA_TARGET и SHOW SGA (V$SGA) начинает казать как при выставленном SGA_TARGET. У тебя они точно не установлены ? (show parameter size, только,ради бога, в тегах SRC или хотя бы FIX) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2018, 14:21 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Вячеслав Любомудров Про жесткое соотношение и реальный объем это ты сам придумал На самом деле понял из этой цитаты : nata44845 помню, у оракла есть особенность, когда задана memory_target он делит ее в соотношении 60/40. И поэтому, я и начал объяснять, что это не так (в плане жесткости) и что пугаться 40 на 60 нет никакого смысла. (Не имеет никакого значения то, что возникает при старте, если дальше оно начинает динамически меняться ): причем координальным образом) В противном случае, не стал бы тратить свое время. И тем более советовать использовать именно этот режим работы, как это и рекомендует оракл, при условии, что нет противопоказаний и человек не очень разбираеться что и на что выделять. Вячеслав Любомудров Естественно, в процессе работы оно будет меняться в зависимости от нагрузки (более того -- будут меняться размеры компонентов внутри SGA) -- на то это и автоматическое управление памятью. Именно этому объяснению я и посвятил предыдущие свои комменты !!! Вячеслав Любомудров Вот тебе еще и на Бурлесона ссылочка, он, как обычно перепощивает металинковские ноты своими словами Благодарю. Я им тоже достаточно часто пользуюсь. Вячеслав Любомудров И вот еще -- можно ведь выставить нижние пределы (например DB_CACHE_SIZE, SHARED_POOL_SIZE) -- вот есть подозрение, что при этом неявно выставляется нижний предел SGA_TARGET и SHOW SGA (V$SGA) начинает казать как при выставленном SGA_TARGET. У тебя они точно не установлены ? (show parameter size, только,ради бога, в тегах SRC или хотя бы FIX) Ну если интересно, то: SQL> show parameter size; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ bitmap_merge_area_size integer 1048576 client_result_cache_size big integer 0 create_bitmap_area_size integer 8388608 db_16k_cache_size big integer 0 db_2k_cache_size big integer 0 db_32k_cache_size big integer 0 db_4k_cache_size big integer 0 db_8k_cache_size big integer 0 db_block_size integer 8192 db_cache_size big integer 0 db_flash_cache_size big integer 0 db_keep_cache_size big integer 0 db_recovery_file_dest_size big integer 50000M db_recycle_cache_size big integer 0 dnfs_batch_size integer 4096 global_context_pool_size string hash_area_size integer 131072 java_max_sessionspace_size integer 0 java_pool_size big integer 0 large_pool_size big integer 0 max_dump_file_size string unlimited object_cache_max_size_percent integer 10 object_cache_optimal_size integer 102400 olap_page_pool_size big integer 0 parallel_execution_message_size integer 16384 result_cache_max_size big integer 0 sga_max_size big integer 7372M shared_pool_reserved_size big integer 60188262 shared_pool_size big integer 0 sort_area_retained_size integer 0 sort_area_size integer 65536 streams_pool_size big integer 0 workarea_size_policy string AUTO Сразу оговорюсь, что в spfile у меня стоит: *.sga_max_size=0 *.sga_target=0 прочие перечисленные DB_CACHE_SIZE, SHARED_POOL_SIZE не использую ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2018, 16:26 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Версия до 11.2.0.3 ? Вот там вроде как если SGA_ MAX _SIZE не задан, то он выставляется как 60% MEMORY_TARGET. Начиная с 11.2.0.3 он выставляется равным MEMORY_TARGET (за исключением 32-битной винды). Это вне контекста о изначальном 60/40 для динамических SGA_TARGET/PAT. Это жесткий лимит именно SGA. Баг или не баг -- хрен знает. Сам не сталкивался. см. https://community.oracle.com/thread/2410066 Поэтому у тебя в выводе V$SGA "Total System Global Area" и не равно MEMORY_TARGET (как раз и равно SGA_MAX_SIZE) Это, кстати, означает, что SGA_TARGET у тебя никогда не превысит твоих 7.5 гигов, поэтому лучше выставить явно SGA_MAX_SIZE=MEMORY_TARGET ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2018, 07:21 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Вячеслав Любомудров, Было такое на 11.2.0.1, очень бесило, что вот она память есть, а оракл SGA не увеличивает, поэтому стала задавать SGA_TARGET вручную. Ну и SGA_MAX_SIZE соответственно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2018, 07:30 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
стоит 11.2.0.4.0 - 64bit. Но не суть. Проблем с этой БД вроде нет. Может быть и баг, а раз баг, то выйдет ли SGA за пределы своего MAX в пределах всего выделенного ему MEMORY - тоже вопрос. В коде ведь никто не копался, как оно реализовано на уровне С/C++ - знает, наверное только тот, кто это писал. Прочему бы и нет :) все эти 40 на 60 - они ведь в официальной доке отсутствуют - нычкуют по металинкам по нотам. nata44845 Было такое на 11.2.0.1, очень бесило, что вот она память есть, а оракл SGA не увеличивает, поэтому стала задавать SGA_TARGET вручную. Ну и SGA_MAX_SIZE соответственно. А вы под нагрузкой пробовали на memory_target-е? Может быть под нагрузкой он преодалеет свой макс - "баг ведь :)" - я и такое допускаю, хотя и признаю, что не логично. Понимаете, если SGA_MAX_SIZE выставлять при выставленном memory_target, тогда зачем вообще нужен memory_target ? Ведь, memory_target везде в доках превозносится как лучшее решение. В принципе на маленьких БД меня устраивает, ну а на больших я использую раздельное управление SGA_TARGET и SGA_MAX_SIZE, PGA_TARGET, но тогда memory_target соответственно в 0. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2018, 12:12 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
По поводу VSS под виндой, чтоб не искать, действительно утечка памяти https://blog.zeddba.com/tag/ora-04030/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2018, 06:27 |
|
||
|
ORA-04030: out of process memory when trying
|
|||
|---|---|---|---|
|
#18+
Убедитесь в корректности установки soft and hard limit of stacksize, проверьте в соответствии с installation guide для вашей ОС, версии RDBMS. Используйте HCVE script from RDA - Health Check / Validation Engine Guide ( Doc ID 250262.1 ). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2018, 02:20 |
|
||
|
|

start [/forum/topic.php?all=1&fid=52&tid=1883087]: |
0ms |
get settings: |
10ms |
get forum list: |
21ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
93ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
86ms |
get tp. blocked users: |
2ms |
| others: | 257ms |
| total: | 493ms |

| 0 / 0 |
