Just curious, how will increasing vm.min_free_kbytes make any difference? Let’s say I set this to 5% of my memory, won’t the kernel still scan PageTables when memory usage hits 95%?

We’re experiencing an issue similar to this, where whenever a system releases a large amount of PageTables (1-2gig’s worth), we see a sharp spike in System CPU. Is there anything we can do to prevent this, or is hugepages the only option?

I’m learning about linux memory and hugepages, and thought I’d experiment with it by replicating the issue you described in your post. First, I’ve written a small C program (http://pastie.org/1606226) that basically just eats 20 GB of memory. After running the program on my RHEL 5 server I was expecting the PageTable to be huge, but found that it was only about 43 MB. The page size on my RHEL box i 4 kB.

Can someone here maybe clear up why I’m not seeing such a major PageTable size issue like the one described in the post, and perhaps how to reproduce it (without actually running a database)?

Best regards,
Kenneth Holter

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/