Re: Anonymous huge pages for Linux

LOL, no worries, I got a laugh. The problem is that we might have 10 to even 50 db on the same server. Although each db will be small, they do require their own instance, and pluggable db are not supported in the application.
This might be a situation where I do not use huge pages at all, and take the performance hit in favor of reliability.

On Mon, Jan 9, 2023 at 6:25 PM Todd Bellaver <todd.bellaver_at_gmail.com> wrote:

> Jon,
>
> My apologies for the sharp NO. It was an echo from when a bunch of us
> talked about this over a night of DBA debauchery. Mark, thanks for the
> better answer.
>
> My 2-cents. Consider configuring your Oracle DB server build policy to
> set huge pages to 40% of physical memory. This 40% is for the *combined*
> SGAs of all the databases on the database server. The other 60% is for the *combined
> *PGA Aggregate Limits (*not targets*) of all the databases on that server
> and OS. 40% is just a suggestion, 35% may be better. Do the math for what
> works best for your environment.
>
> I hope this is also a better answer.
>
> Best of luck on your Oracle adventures.
>
> Todd
>
>
>
>
> On Mon, Jan 9, 2023 at 5:26 PM Mark J. Bobak <mark_at_bobak.net> wrote:
>
>> To the best of my knowledge, anonymous husepages are still a non-starter
>> when it comes to Oracle.
>>
>> On Mon, Jan 9, 2023 at 3:44 PM Jon Crisler <joncrisler_at_gmail.com> wrote:
>>
>>> Has anybody had success using anonymous huge pages in later versions of
>>> Red Hat or OEL ? The accepted practice has been to disable anonymous huge
>>> pages and use fixed huge pages, due to performance issues and bugs.
>>> However we are working on a project that may require the rapid provision
>>> of small test databases, which will make maintaining manual huge pages a
>>> headache. If anonymous huge pages work well now, that would be my
>>> preferred configuration.
>>>
>>

--
http://www.freelists.org/webpage/oracle-l