Hugepages is not a derived value, but an optional setting if you want to use Hugepages. So, if # of Hugepages is set to 2048, then you would have allocated 4G(2048*2M – assumption Hugepagesize=2M) of Hugepages space.

You can now create the SGA, which is allocated from the Hugepage space.

Thanks a lot for such meaningful and rare information about HugePages. I have a question thought (I may be confued or did not read your blog properly)

My question is:

How do we calculate the HugePages will it be like:

Let’s assume my SGA is 4GB and my Hugepagesize is 2048KB then my HugePages would be 4*1024*1024 (to convert it into KB) and then divide it with 2048??

(4*1024*1024)/2048=2048 (round off to 3000)???

Please correct me if I am wrong.. Also let me know how the same will work in 32Bit Linux

I spent the majority of my time in the Oracle Database 11g Beta program testing storage-related aspects of the new release. To be honest, I didn’t even take a short peek at the new Automatic Memory Management feature. As I pointed out the other d…

“It gets a few hundred connections at a time” is key to this whole thread and deserves more attention. The multiplier affect of non-shared page tables is what was eating up so much memory. For every foreground process the system required 10MB of page tables. There seems to have been about 500 dedicated connections at the time meminfo was examined.

As for “Most likely, much of SGA pages also can be paged out, since SGA is not locked in memory”, it is true that SGA pages can be swapped out…*only if* they have only been touched by one process. Mutliply referenced shared pages do not get swapped. Allowing this sort of swapping would cause a horrible chain reaction. After all, there are more than one processes using SGA pages. That aside, the page tables mapping the SGA are swapable. It is easy to account for the 4.7GB leaps in available memory you measured with sar by the simple swapping of the data,stack and page tables of just a percentage of the huge number of processes running on the system.

Mladen is right about the cost of losing AMM from a managability perspective.

I blogged about 11g AMM quite a while ago as well:

http://kevinclosson.wordpress.com/2007/08/23/oracle11g-automatic-memory-management-and-linux-hugepages-support/

Thanks for your kind words.

1. I just tested it out in my linux server running 2.6 kernel. ASMM uses hugepages, as long as, available hugepages is greater than sga_max_size. ML note you referred is for 32 bit+use_indirect_buffers and Of course, use_indirect_buffers will not work with hugepages. But, ASMM itself works fine with hugepages.

11g AMM will not work with hugepages though.

2. You are right, I should have said “5GB pagetable” need to be scanned. Nevertheless, scanning 5GB of page table will consume enormous amount of CPU.

Thanks for those paging parameters. I see your point that if all these parameters are optimally setup, we might be able to reduce this effect.
I would rather prefer to keep page table itself much smaller, two reasons: 1)Bigger page table results in higher CPU usage from user processes due to higher TLB misses 2) Unnecessary waste for page table memory. For e.g., in this specific scenario, after setting up hugepages, pagetable size went down from 5GB to 400MB, a net gain of 4.4GB. We could allocate this memory to SGA allowing further gain.

Hi Cristian
Thanks for reading our blog. We might need more data to understand your specific situation.

Cheers
Riyaj