locked
Memory limit in 64 bit .NET RRS feed

  • Question

  • We have a windows service that is written in .NET 2.0 that somtimes may use large amount of memory. This is normal since we have lots of simultanious users that load some data.

     

    As I understand it, there's a limit for 32 bit .NET process around 1.6GB (2GB minus some). This is understandable, but I was pretty surpriced that there actually seems to be a 4GB limit when running as a 64 bit process!

     

    Is this really true?

    Can't find any documentation about this. If this is true, then 64 bit isn't that much of an advantage after all.

     

    One major drawback is when we hit the limit and get a OutOfMemoryException, then the service may survive, but under heavy load it may crash and we have to restart the service (all users are logged off!). Sad

    It would be ok if all users got OutOfMemoryException and the service just kept going...

     

    Will there be any changes to these issues in .NET 3.5?

     

    As I said, I can't find any documentation about this, but there should be somewere on the microsoft site?

     

    /Andreas

    Wednesday, July 4, 2007 9:36 PM

Answers

  • Just because you are running 64-bits doesn't mean you have access to a lot more memory.  It is still limited by the OS. What OS are you running?  Keep in mind that the per-process limit is different than the system memory limit.  Under 32-bit processes are limited to 2GB by default (3GB with a flag) while the OS gets the other 2GB.  64-bit XP has access to 128GB AFAIK.  However if you run a 32-bit app on it then you're back to 2GB again.

     

    BTW if your app is eating up 4GB (or even 2GB) of memory then you have a serious problem.  You should never have a need for that much memory except maybe if you were writing a database app or something. 

     

    Michael Taylor - 7/4/07

    http://p3net.mvps.org

     

    Wednesday, July 4, 2007 11:14 PM
  • maybe it's something trivial: to which size did you set your pagefile? The amout of virtual memory usable can't of course be greater than your amount of physical memory + the size of the page file.
    Thursday, July 5, 2007 11:58 AM
  • It helped increasing the pagefile, windows didn't increase it automatically.

    Seems to be no limit (or high enough!) in 64 bit .NET after all. I have read on some old blogs that there might be the same limit as in 32 bit for a single process, but this isn't true then.

     

    I'm still interested in any kind of public documentation from microsoft that describes this.

     

    Thanks!

    Thursday, July 5, 2007 12:18 PM
  • When you say that you can only use 4GB what do you mean? Are you finding youself limited in creating a single large object (e.g. a large array) or in creating lots and lots of small objects?

     

    The 64-bit CLR does have a limitation on the size of a given managed object (including arrays). However, we definitely can allocate more than 4GB worth of objects.

     

    I discuss the limitations on object size here: http://blogs.msdn.com/joshwil/archive/2005/08/10/450202.aspx

     

    -josh

    http://blogs.msdn.com/joshwil/

    Monday, July 9, 2007 4:45 PM

All replies

  • Just because you are running 64-bits doesn't mean you have access to a lot more memory.  It is still limited by the OS. What OS are you running?  Keep in mind that the per-process limit is different than the system memory limit.  Under 32-bit processes are limited to 2GB by default (3GB with a flag) while the OS gets the other 2GB.  64-bit XP has access to 128GB AFAIK.  However if you run a 32-bit app on it then you're back to 2GB again.

     

    BTW if your app is eating up 4GB (or even 2GB) of memory then you have a serious problem.  You should never have a need for that much memory except maybe if you were writing a database app or something. 

     

    Michael Taylor - 7/4/07

    http://p3net.mvps.org

     

    Wednesday, July 4, 2007 11:14 PM
  • Well, I am writing a database application and yes it's running as a 64 bit process on a 64 bit OS (Windows Server 2003 x64).

    Still can't use more than 4GB!

     

    It is not a problem that my app use that much memory since it is always released when the current threads has finished.

    Your customers are willing to put in as much memory as we need, if we just could use it!!!

    For most of our installations it's enough with 2-4GB, but we have a few extreme installations with lots of simultanious users where this is not enough.

     

    /Andreas

    Thursday, July 5, 2007 7:02 AM
  • maybe it's something trivial: to which size did you set your pagefile? The amout of virtual memory usable can't of course be greater than your amount of physical memory + the size of the page file.
    Thursday, July 5, 2007 11:58 AM
  • It helped increasing the pagefile, windows didn't increase it automatically.

    Seems to be no limit (or high enough!) in 64 bit .NET after all. I have read on some old blogs that there might be the same limit as in 32 bit for a single process, but this isn't true then.

     

    I'm still interested in any kind of public documentation from microsoft that describes this.

     

    Thanks!

    Thursday, July 5, 2007 12:18 PM
  • When you say that you can only use 4GB what do you mean? Are you finding youself limited in creating a single large object (e.g. a large array) or in creating lots and lots of small objects?

     

    The 64-bit CLR does have a limitation on the size of a given managed object (including arrays). However, we definitely can allocate more than 4GB worth of objects.

     

    I discuss the limitations on object size here: http://blogs.msdn.com/joshwil/archive/2005/08/10/450202.aspx

     

    -josh

    http://blogs.msdn.com/joshwil/

    Monday, July 9, 2007 4:45 PM
  • One can easily exceed 2GB of RAM in a single element when one does data analysis on high resolution data by using the "wrong" adressing scheme.  Declaring your array as [width,height] will fail much faster than [width][height].   We saw this at first when processing a 300MP image.
    bryan
    Wednesday, May 27, 2009 5:45 PM