Re: hugepages question

  • From: "Mark J. Bobak" <mark@xxxxxxxxx>
  • To: Andy Wattenhofer <watt0012@xxxxxxx>
  • Date: Thu, 14 Feb 2019 10:26:42 -0500

I agree with everything Andy just said, except:
"So your vm.nr_hugepages times 2MB times 1024kB will give you your huge
pages in kilobytes"
This should be "divided by" ----------------^^^^

On Wed, Feb 13, 2019 at 11:25 PM Andy Wattenhofer <watt0012@xxxxxxx> wrote:

Now that you have re-created the database, if you shut it down and start
it up does it still raise that error (assuming use_large_pages=ONLY)?

A *guess* I have is that your memlock for the oracle user in
/etc/security/limits.conf is too low, like lower than the number of bytes
you have reserved via the vm.nr_hugepages parameter. So for example, the
output from this:
grep nr_hugepages /etc/sysctl.conf

tells you how many huge pages you have allocated, which are 2MB each. So
your vm.nr_hugepages times 2MB times 1024kB will give you your huge pages
in kilobytes. That must be less than your oracle user memlock limit (kB)
from this:
grep memlock /etc/security/limits.conf
(if it's not set in there, 'ulimit -l' will show you what it is defaulting
to instead)

If memlock is too low, the oracle user cannot lock enough physical memory
into its address space, which is a requirement for allocating huge pages.
In your case, my guess would be that as soon as you shut the clone database
down, it freed some space within the memlock limit and something else that
is not huge pages took it. You can set the oracle user memlock limit
'unlimited' or at or near the amount of physical memory on the server to
solve this.

There are other things that I can think of, but it matters what is going
on with the other databases: their use_large_pages and pre_page_sga
settings, their sga_target and sga_max_size settings, plus the amount of
physical memory on the server and your vm.nr_hugepages setting. Generally
speaking, you want sga_target=sga_max_size and the sum of all the
sga_targets must be less than the huge pages you have reserved via
vm.nr_hugepages.

Andy

On Wed, Feb 13, 2019 at 6:11 PM Jeff Chirco <backseatdba@xxxxxxxxx> wrote:

Ok I just recently enabled hugepages on Production and Development.
Everything is going good but I noticed that on my development environment
which consists of a bunch of thin clones, when I remove and recreate the
same clone the database fails to create, I am getting:

ORA-27137: unable to allocate large pages to create a shared memory segment

I have the parameter *use_large_pages=ONLY*
So it makes sense I would get this error when there is not enough pages.
However I just removed this same database and am recreating it. I would
think that would free it up but apparently not.  Does pages not get
released immediately when a database is removed? Is there something I
should run to free it?  Or just not have use_large_pages=ONLY and leave it
at TRUE on Dev?  I had to set it to TRUE to get this database up.

Thanks,
Jeff


Other related posts: