Re: hugepages question
Date: Thu, 14 Feb 2019 10:26:42 -0500
Message-ID: <CAFQ5ACK5oW=U=86xar08k+pa_=fh6zMUYU_ZQW_kWgdmg0vVKA_at_mail.gmail.com>
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_at_umn.edu> 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_at_gmail.com> 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
>>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Thu Feb 14 2019 - 16:26:42 CET