Large Security Tokens and Kernel Memory Exhaustion

re: Large Security Tokens and Kernel Memory Exhaustion

Matt Drnovscek — Thu, 29 Dec 2005 17:46:09 GMT

Hi Guys, love the site, great article. Mabye you can clean up a little confusion on my end. I thouht that under W2K if you enabled the Non-Paged pool (NP Pool) was limited to 256MB and with the /3GB switch the NP Pool was reduced by 50% to 128MB. When we were running EX2K on W2K we would start to see problems when the NP Pool reached about 96MB.

Now in this article you mention that by default in W2K3 that the NP Pool is 350MB and when using the /3GB switch it reduced to 250MB. Did MS increase the the amount of memory that the kernal allocates to the NP Pool in W2K3?

A related Q on PCI-E servers this blog has mentioned that we should also implement /PAE (to deal with the way PCI-E allocates RAM on servers with large amounts of RAM) how does this effect NP Pool consumption on W2K3 any clarification would be appreciated as it would help us (and your other readers) better monitor their systems.

Many Thanks,
M@

re: Large Security Tokens and Kernel Memory Exhaustion

Mike Lee — Thu, 29 Dec 2005 21:56:23 GMT

You are correct, Matt, that using /3GB reduces NON-PAGED pool space by half (from 256 MB to 128 MB). It also reduces PAGED pool from about 350 MB to 250 MB.

Large tokens have the most impact on PAGED pool memory rather than on NON-PAGED memory. It is true that tokens require some NON-PAGED memory, but the impact is much less than on PAGED memory.

As far as PCI-Express goes, it "steals" some address space beneath the 4 GB boundary. Typically this is 256 to 512 MB. For a machine with 4GB of physical RAM, this makes that amount of RAM unuseable/unaddressable.

You can use /PAE to "unhide" the RAM. Yes, this will use an increment of kernel resources. Unless you're on the ragged edge already, it shouldn't be that significant. But unhiding this RAM is unlikely to provide any significant benefit either to the server's performance.

You can test exactly what happens on your particular machine by booting with and without various memory tuning startup options. For more detail about PAE and Exchange, see this previous blog entry:

http://blogs.technet.com/exchange/archive/2005/12/14/416065.aspx

re: Large Security Tokens and Kernel Memory Exhaustion

Bernard K — Fri, 30 Dec 2005 16:11:51 GMT

Hi,

Thanks for these interesting info.

When trying to measure client activity on E2K3 server,there is "Connection count" perfmon counter at the MSExchangeIS level and "Client logons" at "MSExchangeIS Mailbox" (and "MSExchangeIS Public"). The "connection count" increases at the first access from Outlook to a server. The "client logons" increases the first time a client opens his mailbox, a secondary mailbox or a folder on the server. Can you indicate which counter better links to token consumption.

In terms of paged pool usage, is it interesting (and why) to gather mailboxes according to entities they belong to ? We have an important usage of calendar (meeting requests with resolution of items in free/busy...), secondary mailboxes and delegates. This is almost exclusively done between people of same entities.

When trying to simulate client activity with loadsim, it can be seen that paged pool consumption behaves badly when a lot of clients start in a short delay. Paged pool usage then slowly decreases while activity remains identical. Is there a way to improve paged pool memory recollection ?

Thanks

Happy New Year

Bernard K

re: Large Security Tokens and Kernel Memory Exhaustion

Matt Drnovscek — Fri, 30 Dec 2005 17:01:58 GMT

Thanks for the feedback guys... as always it pays to have a coffee before you reply to a post - as you all know caffene helps one to remember the difference between Paged & Non Paged pool :). Many thanks for all of the help and have a happy new year.

Regards,
M@

re: Large Security Tokens and Kernel Memory Exhaustion

Andrew Hitchcock — Tue, 03 Jan 2006 22:15:36 GMT

Great article. Slightly off topic question:

So you say: "You can simplify group administration by following the best practice of not nesting groups beyond two levels."

Where can I find this "best practice". Users in Global, Global in Universal, Universal in Local; I'm very familiar with this. I was under the impression that within each scope you can nest if required. I've never seen any thing stating that you should not nest groups beyond two levels. I was not aware that nesting within a scope was considered outside of "best practice".

What can happen during OAB full downloads, how to control it and what you need to know!!

Dgoldman's WebLog — Sat, 11 Feb 2006 02:41:55 GMT

Often in large corporate environments, network bandwidth consumption is a crippling issue. One of the...

Exchange hotfix for kernel memory exhaustion issues is now released

You Had Me At EHLO... — Mon, 27 Feb 2006 21:48:17 GMT

EXECUTIVE SUMMARY
&nbsp;
A few weeks ago,&nbsp;we released three CXP flashes&nbsp;on the subject of...