Re: Large pages

From: Noons <>
Date: Sun, 25 Nov 2012 03:06:44 -0800 (PST)
Message-ID: <>

On Nov 23, 11:34 pm, wrote:

> What I have tested on databases on AIX 5.3 is backing them by 64K pages, in reference to an IBM document:
> and also input from Doug Burns and Maxym Kharchenko:
> and also input from some MetaLink notes.
> Quote from page 13 of IBM's document:
> "The new 64 KB pages are preferred over 16 MB pages, and it is recommended that you use them instead of 16 MB pages on systems that support both page sizes. This is because 64 KB pages provide most of the benefit of 16 MB pages, without the special tuning requirements of 16 MB pages."

Now, you see: right there, is some mighty confusion.

First of all: page 13 of the document does NOT say that. Note: I am FULLY aware of the Massanari documents: there are multiple versions of them and some other better documents. Nothing new.

The quote is out of context. What the doc says is that we can use 16MB large pages for the SGA, but if we ALSO use large pages for code and text, those should instead use 64KB large pages. Which is perfectly correct. And nothing to do with what I said: I made it very clear that I was referring only to the SGA.

But the way you quoted it, it sounds like 16MB pages are incorrect for ANYTHING. Wrong: they are correct for the SGA and should be used for it.

From the SAME page of that document:

"When using large pages to map virtual memory, the translation lookaside buffer (TLB) is able to map more virtual memory with a given number of entries, resulting in a lower TLB miss rate forapplications that use a large amount of virtual memory. Additionally, when using large pages, thereare fewer page boundaries, which improve the performance of prefetching. Both online transactionprocessing (OLTP) and data-warehouse environments can benefit from using large pages"

THAT is the really important bit that I urge you to understand in depth. All other "recommendations" and "rules of thumb" are dross.

As well and with all due respect: Doug and Maxim are not exactly Aix experts for Oracle and the link you provided is for 11g testing or a very specific feature: dynamic SGA resizing with large page sizes and it doesn't even mention which Aix release is being used. Being a member of the Oaktable/Ace/whatever is NOT a certificate that one is fully knowledgeable in EVERYTHING and we should all follow blindly what is said without any reasoning being applied.

I urge you not to confuse apples with oranges: it does NOT work when dealing with subtle and complexe subjects such as memory management.

And as I said in a comment to Maxim's blog: if anyone thinks dynamically changing SGA size is an operation that one wants to do very often if at all, large pages or not, then I've got a bridge to sell them. So, what's the point of even considereing it?

Dynamic SGA memory resizing is one the most imbecile features introduced to Oracle recently, to cater for idiots who can't configure a system upfront. The result is the mountain of bugs reported in MOS when using that feature. I wish that for once the "auto-everything" madness would abate...

> In my tests it was as simple as:
> export ORACLE_SGA_PGSZ=64k
> before starting up the database.

Careful with that LDR_CNTRL. It does NOTHING whatsoever to control what pagesize the SGA uses. It exclusively deals with the program execution from there on. If you don't include it in ALL programs/ scripts/sessions/anything that runs in that server, it will be mostly useless when used to start the instance. Go back to the example I gave for Jonathan: it shows the effect of that environment variable and what it does to sqlplus. It's got nothing to do with theSGA itself.

Or rather: given that once again we are going into "what the summity says" instead of analyzing things properly and rationalizing what is being done in full knowledge, I'd rather you didn't change anything.

I really can't be bothered with religion and quite frankly, the Oracle community nowadays is nothing else than a "church of the Ace". Sorry, but I really don't have time for that sort of bull. Good bye and keep using Oracle's "engineered systems" instead of true leading edge hardware: it's a lot "safer"... Received on Sun Nov 25 2012 - 12:06:44 CET

Original text of this message