Stefan,
That doc looks interesting. Wish I knew more about _use_realfree_heap.
Doing some searching (my current setting is TRUE). Also wonder if the 16GB
hard limit mentioned in that doc could also be 32 GB as I am seeing.
Henry
On Thu, Mar 16, 2017 at 3:02 PM, Stefan Koehler <contact@xxxxxxxx> wrote:
Hey Henry,
Could there be another place that Linux is limiting the process?
Linux x86_64 has a theoretically VAS (virtual address space -
https://www.kernel.org/doc/Documentation/x86/x86_64/mm.txt) limit of 128
TB :-)
Has the Oracle PGA allocation changed in 12c?
Yes and no (depends on what you compare it with). Realfree memory
management / allocator ( mmap() and munmap() ) was introduced with Oracle
9i and
there was a limit of 16 GB when using it. However this limit was raised to
80 GB by bug fix #14119856 but personally i have never tested it as my lab
does not have 80 GB of RAM - i am just a poor independent guy, you know ;-)
Just try to disable realfree memory management / allocator (SQL> alter
system set "_use_realfree_heap"=FALSE;) and check if you can use more heap
memory.
Best Regards
Stefan Koehler
Independent Oracle performance consultant and researcher
Website: http://www.soocs.de
Twitter: @OracleSK
Upcoming online seminar: http://tinyurl.com/17-06-13-Shared-Pool-Internals
Henry Poras <henry.poras@xxxxxxxxx> hat am 16. März 2017 um 18:19geschrieben:
aggregate function which is instantiating lots of (untunable) pga memory.
I am running on Oracle 12.1.0.2
We are currently getting 4030 (timobj call) which I have tracked to an
is erroring out at 32GB. I am trying to see if this is an Oracle limit (in
Our pga_aggregate_target is 700GB and
our pga_aggregate_limit is 900G
We are not coming close to using our aggregate memory, yet the process
the past versions, this kind of untunable allocation would continue torise) or a linux one.
Could there be another place that Linux is limiting the process? Has the
I have checked both ulimit -a and ulimit -Hm with both being unlimited.
Oracle PGA allocation changed in 12c?
Thanks.
Henry