Why does Exchange recommend /3GB if you have more than 1GB of physical memory?

Date:August 13, 2004 / year-entry #306
Tags:other
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20040813-00/?p=38173
Comments:    17
Summary:If you look through the Knowledge Base, you'll see an article that say that Exchange 2000 requires the /3GB switch with more than 1 gigabyte of physical RAM. Yet I've been writing all this time that /3GB has nothing to do with physical RAM. What's the deal? The title of the article could be a...

If you look through the Knowledge Base, you'll see an article that say that Exchange 2000 requires the /3GB switch with more than 1 gigabyte of physical RAM. Yet I've been writing all this time that /3GB has nothing to do with physical RAM. What's the deal?

The title of the article could be a bit clearer. It really should be something more like "Exchange 2000 requires the /3GB switch to take advantage of more than 1 gigabyte of physical RAM".

It appears that Exchange 2000 doesn't use the bank-switching technique I described in an earlier entry. (I don't blame them. It's extraordinarily cumbersome.) Consequently, for Exchange 2000, virtual address space equals virtual memory.

The capacity of a program is typically a combination of multiple factors, the lowest of which sets the limit. By analogy, suppose you need two piece of bread, two pieces of bologna, and a slice of cheese to make a bologna and cheese sandwich. Whichever ingredient you run out of first determines how many sandwiches you can make. If you run out of cheese first, adding more bologna won't help any.

Okay, so what do bologna and cheese sandwiches have to do with Exchange 2000?

From the description in the article, it appears that the store.exe program is RAM-constrained most of the time (you run out of cheese first). But once you get the memory on the machine up to one gigabyte, you have excess RAM and address space becomes the new limiting factor. (You added plenty of cheese and now you've run out of bologna.) That's where the /3GB switch comes in. It increases the user-mode address space, thereby relieving pressure on the address space constraint.


Comments (17)
  1. Yann says:

    Today is a black day. I only discovered this weblog a few weeks ago. Then I went on holiday. Since I’m back, I’ve been reading all entries and all comments. Now I’m competely up-to-date. That means that I have to wait until 7AM everyday for a new entry of Raymond. I’m a bit sad…

  2. John Bergman says:

    Is this also true for Exchange 2003? I hunted around on Microsoft’s support site and could not find any indication that the /3GB is required to improve performance there.

  3. Miles Archer says:

    Now I’m really confused. I thought I understood address space/virtual memory and the 3G switch.

    Are you saying that Exchange doesn’t use the full 2GB of virtual memory if there is less than 1GB of real memory?

    Or is it that Exchange gets the full virtual address space, but Windows doesn’t allow it to get more than 1GB of real memory. If so, why is that. Is it something special about Exchange?

  4. I agree with Miles. Are you sure it’s recommending /3G with more than 1G of RAM? It would seem to me that the recommendation should kick in with more than 2G of RAM.

  5. Marc says:

    Though the article mentiones in Raymond’s entry states the 3Gb swicht can be used on Advanced Server only because of fragmentation on Win 2000 server and alike.

    How comes? What makes the OS behave in a different way?

  6. Raymond Chen says:

    Aw come on guys; now you’re not even trying. You’re making mistakes even more basic than the ones I’m trying to demystify.

    1. There are things in your address space aside from data. (You may have heard of "code".)

    2. Just because it’s in your address space doesn’t mean it needs RAM. ("Working set")

    3. Address space allocation granularity is 64K. ("Fragmentation".)

    COMPLETELY MAKING UP NUMBERS: Suppose that in order to support n users, store.exe needs 512MB+n*64K of address space and 256MB+n*8K of RAM. So if you have 24000 users, that means you need 1.96GB of address space and 700MB of RAM. If you add 1GB, the extra 300MB doesn’t help you increase "n" because you’ve already hit the address space limit.

    I tried to use the bologna sandwich analogy as an example of "resource that runs out first sets the limit" but apparently that didn’t make the point well enough.

  7. Skywing says:

    Windows 2000 Professional and Windows 2000 Server ignore the /3GB switch. You need to buy Advanced Server if you want it.

  8. timchen says:

    You can’t always trust knowledge base articles. Using /3GB here just prevents the address space being fragmented and used up, but based on my experience, this does not happen that often under 2GB space. This also has nothing to do with the RAM size.

    Apart of this, you won’t get a performance raise (more VM = more paging). Plus, you don’t need to worry about wasting RAM as the system cache will use a lot of RAM anyway and 1GB RAM is always not enough (think about the size of all the mailboxes).

    And the poor size of paged/nonpaged pool, system ptes under /3gb…

  9. Mike Dimmick says:

    KB article 867628 (http://support.microsoft.com/?id=867628) mentions that the Jet cache was shown as ‘mapped bytes’ before Exchange 2003 SP1 but as ‘private bytes’ afterward. This suggests they’ve changed calls to CreateFileMapping( INVALID_HANDLE_VALUE, … ) to VirtualAlloc. I’d have expected the code to just map the appropriate areas of the files, though, which I believe is how SQL Server works.

    I don’t expect they’ve made the mistake of using VirtualAlloc to allocate a single page, but reserve the whole 64KB (remember that virtual address space is reserved in 64KB blocks).

    I seem to recall seeing somewhere that the next version of Exchange was to use a common data storage engine, shared with SQL Server. Last I heard, though, Exchange ‘Kodiak’ has been postponed until the Longhorn Server timeframe.

  10. Raymond,

    My 1G point was that Exchange is a server. And as you’ve said, for servers, paging=death. If an Exchange store ever used more than 2G of virtual address space on a machine with 1G of RAM, then it’d be paging itself to death. And that would be a VERY bad thing.

    So I’m confused as to how /3G benefits an Exchange server with only 1G of RAM. An Exchange server that’s spending all its time paging in memory isn’t servicing those users.

  11. Norman Diamond says:

    8/16/2004 4:25 PM Larry Osterman

    > If an Exchange store ever used more than 2G

    > of virtual address space on a machine with

    > 1G of RAM, then it’d be paging itself to

    > death.

    If it used 2G of virtual memory in its working set, yes. If it used 2G of virtual address space but didn’t actually store anything in half the pages, its working set would still be 1G. Which of these situations actually occurs?

  12. Exchange uses VM for two things. The first is for the database buffers (cache, transaction lookaside lists, etc). That takes about 75% of available physical memory (this is a guess, the actual percentage is configurable). The database memory is allocated in a single honking great big allocation and is carved up by the database internally.

    The rest is used up for process heaps. In the absence of a memory leak (and there aren’t any), the memory in an Exchange server is churned quite heavily, so all the pages in the heaps tend to be hot.

    Starting with Exchange 2000, Exchange uses fixed sized heaps to reduce memory fragmentation. The only thing that having a 3G address space would do to help is if there weren’t sufficient virtual memory addresses available to allocate a new heap. Which is why I’m surprised at the recommendation.

  13. Oh, and Mike: you don’t want to use memory mapping for your database. You need a higher level of control of the access to the database file than you can get through memory management. Instead, the exchange database has its own internal cache, and it uses non buffered I/O to access the database files (and transaction logs).

  14. DrPizza says:

    "The database memory is allocated in a single honking great big allocation and is carved up by the database internally. "

    Not that big, really. Less than 2 GiB.

    "Starting with Exchange 2000, Exchange uses fixed sized heaps to reduce memory fragmentation. "

    How does that work? Surely there’d still be fragmentation–its fixed-size heaps are surely still going to be internally subdivided to meet application demands, aren’t they?

    Given that fragmentation has persistently been a problem for Exchange it’s somewhat surprising to me that they don’t use a compacting garbage collector of some form.

    I wouldn’t think they’d want to go for managed code or anything like that, but memory fragmentation is one of the things GCs are well equipped to deal with.

  15. Greg Page says:

    You need it, at least, because Exchange support will not help you unless you have it.

    No matter why we need it, the 3GB switch is a horrid thing to do to a server and to me, it shows that Exchange memory manager seems a wee bit of the refactoring.

  16.   As Evan already mentioned on his blog, Raymond Chen has a great series on /3GB switch on his blog. What is really cool is that Raymond takes on some myths about the /3GB switch and  the fact that he…

  17. Attila the Hun says:

    It looks like Savage Nomads was clubbed in the head in the middle of his post. Lets hope he’s ok!

Comments are closed.


*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index