 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / ASP.NET / Caching / September 2004maximizing memory available for cache
Our .NET 1.1 application server has 2GB RAM and is running Windows Server 2003 Standard Edition. The IIS 6 application pool that runs our app is set for "Memory Recycling - Maximum Used Memory: 800MB" (I assume this is the point at which .net will start to expire cache entires and reclaim other memory resources. I further assume this corresponds to the old <processModel memoryLimit> setting, though the processModel setting was percentage based. Finally, I assume the IIS 6 setting is overriding the machine.config <processModel> setting. ) Our ASP.NET process never goes above this 800MB and usually runs at 700MB. In the past, setting the Maximum Used Memory higher has led to Out Of Memory exceptions and other such nastiness. However, when I look at that the machine currently (with a 700 MB .NET process), only 1.3 GB of the 2.0 GB are in use - I seem to be leaving 500-700MB of potential cache storage on the table. Finally the question: 1. How can I go about using as much RAM as possible towards ASP.NET (we need to cache extensively - high traffic, lots of content) - obviously while avoiding dipping into swap? 2. If I want to expand this machine past 2GB RAM, what other hoops must I go through (O/S upgrades? secret registry switches? any other considerations?) Thanks, Jason "Memory is Cheap" Collins Hi Jason, Thank you for using the community. Memory recycling is the equivalent application pool setting for the memoryLimit ASP.NET process model setting. The only difference is that memoryLimit ASP.NET process model setting only uses physical memory. The Memory recycling application pool setting allows you to specify separate limits for physical memory and virtual memory. Memory recycling specifies the maximum amount of memory that a worker process can use. If the worker process exceeds this amount, a new process is created to replace it, and all current requests are reassigned to the new process. To let the ASP.NET worker process use memory as much as possible, you can leave these settings unchecked and set "<processModel memoryLimit" to 90% or more. Anyway, this may impact other services running on same server. If you want to expand this machine with 2GB more RAM, you don't need a OS upgrade or registry switches. Windows server 2003 can handle these staff for us. Hope this help, Luke Microsoft Online Support  SignatureGet Secure! www.microsoft.com/security (This posting is provided "AS IS", with no warranties, and confers no rights.) I'm interested to understand why you suggest using the older <processModel> setting as opposed to the IIS 6 configuration panel? > If the worker process exceeds this amount, a new process > is created to replace it, and all current requests are reassigned to the > new process. Presumably, for this to happen, the ASP.NET cache would all expire first? That is, .NET would do whatever sort of reclamation of memory possible before spinning up this replacement process? Conversely, when this new process is created and all current requests are reassigned to it, the ASP.NET cache is empty (for the new process)? j > Hi Jason, > [quoted text clipped - 27 lines] > (This posting is provided "AS IS", with no warranties, and confers no > rights.) Hi Jason, You are right at that ASP.NET will first expires all cached contents before creating a new process. The reason I suggest <processModel> is that we can values in percent with it, for exmaple, 90%, or 95%. This let IIS appliaction use as much as memoery and we don't need to care about the actual physical memory. Furthermore, the actual memory IIS can use also depends on the 2GB limitation of a Window process. For example, you set memoryLimit to 90%, and the server has 1GB System memory, then IIS can use 900MB; If the server has 2GB, it can use 1.8G; If it has 3GB, it can use 2GB. In my previous message, I may miunderstand your words. I mean, we don't need to perform any thing sepcial to config the new memory, OS will arrange them to application on the server. However, for each process, it still has the limitation of 2GB. To force IIS use more memory, the /3GB boot option is required. Luke Microsoft Online Support SignatureGet Secure! www.microsoft.com/security (This posting is provided "AS IS", with no warranties, and confers no rights.) Ok great - thanks for clarifying. One more question: Our current system occasionally throws Out Of Memory exceptions. We KNOW for 100% certain that there are many, many UNPINNED cache objects that could be released, and yet we see occasions where Out Of Memory exceptions are thrown. Our sites are under heavy load. Is it possible that there is simply a race condition giving rise to these exceptions? That is, some requests are attempting to insert values into the cache at the very instance the cache is being cleaned up, and the race causes the occasional Out of Memory exception to be emitted? We're really looking for the reason behind these OOM "bursts" (we might get a set of 20-30 of them in the span of a few seconds, and these bursts might happen a couple of times per day). If it is a race condition, so be it. It just would be nice to find a reason to account for them. Thanks, Jason > Hi Jason, > [quoted text clipped - 20 lines] > (This posting is provided "AS IS", with no warranties, and confers no > rights.) Hi Jason, Did you mean if an item may be inserted to cache when the asp.net process is recyling? When IIS perform recycling, all the requests assigned to the old process remain pending. When the old process has finished with pending requests and enters idle state, it is terminated. If the worker process crashes, or in anyway stops processing the requests, all pending requests are reassigned to a new process. You may reduce the expiration value for cached object, force they be released from cache in shorter time. Will this help to reduce the Out of memory exception? Additionally, have you found what code cause the exception? Luke Microsoft Online Support SignatureGet Secure! www.microsoft.com/security (This posting is provided "AS IS", with no warranties, and confers no rights.) There is no particular piece of code that causes it; it is quite random. Indeed, the exceptions from the .NET framework have no stack trace! Only "OutOfMemoryException". > You may reduce the expiration value for cached object, force they be > released from cache in shorter time. I don't understand. Regardless of the timeout values, will ASP.NET not aggressively expire cache entries (even before their expiration time arrives) when under memory pressure? That is, aren't ANY cache entries eligible for removal when memory is constrained? We have an 800 MB image, at least 400 MB of that is all ASP.NET cache entries (definitely unpinned objects - we've checked this extensively). Given that ASP.NET is free to recover this 400 MB of cache at any time, I can't understand why we would be seeing Out of Memory exceptions? j > Hi Jason, > [quoted text clipped - 16 lines] > (This posting is provided "AS IS", with no warranties, and confers no > rights.) Hi Jason, The cached object will expired when it reach the timeout event or IIS appliaction reach the memory limitation as we discuss before. When memory is constrained, GC will collect the objects which is not in used, but not aggressively release object in cache. Reducing the timeout value for cached object will force it removed from cache in shorter time, to save memory. Regarding the Out of Memory exceptions, you may also check if it is possible you have some objects not released in the ASP.NET appliaction. Especially, unmanaged components, this also may cause memory usage to increase. Luke Microsoft Online Support SignatureGet Secure! www.microsoft.com/security (This posting is provided "AS IS", with no warranties, and confers no rights.) As mentioned, we have extensively checked for pinned objects and are quite certain that we do not have enough to form leakage significant enough to consume 400MB of RAM twice / day. My original question was: is it possible that there is a race condition under heavy load that would cause OutOfMemoryException to occur - that is, ASP.NET is beginning to recover RAM from the cache, but certain requests happen to hit ASP.NET when RAM is in short supply, as thus a few OutOfMemoryExceptions are thrown? Basically, I'm asking: is it possible that there is a race condition here, or is it GUARANTEED that as long as there is enough memory that can be freed through cache expiration, an OutOfMemoryException will never be thrown? Thanks, j > Hi Jason, > [quoted text clipped - 16 lines] > (This posting is provided "AS IS", with no warranties, and confers no > rights.) Are you allocating memory for very large objects? ex. very large datasets being returned every once in a while? Do you know? Can you check. Anything over 30,000 rows as a ballpark. SignatureRegards, Alvin Bruney [ASP.NET MVP] Got tidbits? Get it here... http://tinyurl.com/3he3b > > As mentioned, we have extensively checked for pinned objects and are quite [quoted text clipped - 34 lines] > > (This posting is provided "AS IS", with no warranties, and confers no > > rights.) We might have some (although I can't think of any), but they aren't living beyond the scope of an Http Request. Why? j > Are you allocating memory for very large objects? ex. very large datasets > being returned every once in a while? Do you know? Can you check. Anything [quoted text clipped - 40 lines] > > > (This posting is provided "AS IS", with no warranties, and confers no > > > rights.) uh huh, have you heard of the VLO bug? Objects allocated on the large object heap (VLO) do not get garbage collected. They linger until the application domain unloads. What this means to you is, if you touch these objects a couple of times a day, your webserver will be brought to its knees. There is a Q-article about this, i can't find it at the moment. Your best bet against this is to set an aggressive cap on the memory limit. If you run into VLO allocation problems, the application pool will recycle unloading the application and giving back the memory. Garbage collection does not make a difference with this bug, that is, the memory is never returned to the process so it keeps on growing. I believe you can find a thread about this in performance or framework newsgroups if you care to google. Somewhere in there is a link to the Q article as well. It's easy to see you getting an out of memory exception when a VLO comes around, or has already been allocated. SignatureRegards, Alvin Bruney [ASP.NET MVP] Got tidbits? Get it here... http://tinyurl.com/3he3b > > We might have some (although I can't think of any), but they aren't living [quoted text clipped - 52 lines] > > > > (This posting is provided "AS IS", with no warranties, and confers no > > > > rights.) Hello Jason, Thanks for posting here. I totally understand your concern. Generally speaking, if there is enough memory in the system for asp.net to consume, it won't throw out OutofMemoryException. There should not be race condition confliction here, at least in theory. However, the truth is that you are encountering this problem now. So we need to troubleshoot the problem, dig into it and find out the root cause. For this type of error, the best way is to get memory dump when exception happens and analyze the dump file. In the memory dump file, we can find much more information such as call stack, memory usage, memory object...For detailed steps, please refer to the following article: "Introduction to Production Debugging for .NET Framework Applications" http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/ DBGch01.asp This guide presents walkthroughs of three scenarios that ASP.NET applications may encounter when running in production environments: memory consumption, contention (also known as "deadlock"), and unexpected server crashes. Hope that helps. Best regards, Yanhong Huang Microsoft Community Support Get Secure! ?C www.microsoft.com/security This posting is provided "AS IS" with no warranties, and confers no rights. Hi, We have had the exact same problem. Once or twice a day, we used to get an OutOfMemoryException on our site, because the ASP.NET cache was overrun. To illustrate the problem, try running the following code. It will invariably trigger the exception or recycle the ASP.NET worker process (.Net 1.1). int count = 100000; int blocksize = 10000; for(int n=0; n < count; n++) { string key = "cacheitem_" + n; object obj = new byte[blocksize]; Cache[key] = obj; } If the process is recycled, the process history will cite the following reason for the shutdown: MemoryLimitExceeded. I should think that this is a bug. A good cache implementation should not let itself be overrun like this. At the very least, it should stop accepting entries, when available memory reaches a certain minimum. Ideally, it should dispose its oldest objects thus freeing memory needed by the new. We have worked around the problem by wrapping all cache access with a custom class that detects low memory situations and cleans up the cache as needed. Best, Ole Thrane Sitecore A/S > Hello Jason, > [quoted text clipped - 11 lines] > detailed steps, please refer to the following article: > "Introduction to Production Debugging for .NET Framework Applications" http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/ > DBGch01.asp > [quoted text clipped - 11 lines] > Get Secure! ?C www.microsoft.com/security > This posting is provided "AS IS" with no warranties, and confers no rights. > I should think that this is a bug. A good cache implementation should not I disagree here. The worker process is hitting the machine config limit causing the application to be recycled. The message, at least in my case for the code provided, explicitly states that the process is being recycled because it exceed the memory cap. Memory is still available for the system but memory allocated for the worker process IS NOT. If you disagree, I will be happy to take a closer look. SignatureRegards, Alvin Bruney [ASP.NET MVP] Got tidbits? Get it here... http://tinyurl.com/3he3b > Hi, > [quoted text clipped - 47 lines] > > detailed steps, please refer to the following article: > > "Introduction to Production Debugging for .NET Framework Applications" http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/ > > DBGch01.asp > > [quoted text clipped - 12 lines] > > This posting is provided "AS IS" with no warranties, and confers no > rights. Hi Alvin, Thanks a lot for your reply. I see your point, but I think that the ASP.NET cache implementation should take into account the machine.config settings. That's what we do in our workaround and it is pretty simple to do. I still think it is very unfortunate that the cache can not be used for large amounts of data without running the risk of exceptions and process recyclings. For every site that uses Session data, a recycle is actually a pretty bad thing that should be avoided if possible. Also, several times we have witnessed ASP.NET go into a state of endless OutOfMemoryException's, where we've had to restart the worker process manually. This state causes lot's of different errors on the site as new objects can not be instantiated. This is not acceptable when at the same time the Cache object may sit on 500MB of data that could be freed without any problems. I think that the Cache object should work much more closely with the GC, so that the GC could notify the cache when memory is drying up. Also, if an OutOfMemoryException occurs anywhere in the worker process, the cache should be cleared immediately in order to try and 'save' the worker process from being recycled. Best, Ole > > I should think that this is a bug. A good cache implementation should not > I disagree here. The worker process is hitting the machine config limit [quoted text clipped - 64 lines] > > > detailed steps, please refer to the following article: > > > "Introduction to Production Debugging for .NET Framework Applications" http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/ > > > DBGch01.asp > > > [quoted text clipped - 14 lines] > > > This posting is provided "AS IS" with no warranties, and confers no > > rights. > Also, if an > OutOfMemoryException occurs anywhere in the worker process, the cache should > be cleared immediately in order to try and 'save' the worker process from > being recycled. I totally agree with you, and would be surprised if the asp.net framework does not already act this way. Alvin, can you comment? Thanks, j > Hi Alvin, > [quoted text clipped - 101 lines] > > > > detailed steps, please refer to the following article: > > > > "Introduction to Production Debugging for .NET Framework Applications" http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/ > > > > DBGch01.asp > > > > [quoted text clipped - 14 lines] > > > > This posting is provided "AS IS" with no warranties, and confers no > > > rights. > > Also, if an > > OutOfMemoryException occurs anywhere in the worker process, the cache > should > > be cleared immediately in order to try and 'save' the worker process from > > being recycled. > I totally agree with you, and would be surprised if the asp.net framework > does not already act this way. I disagree strongly here. An outofmemoryexception exception is a catastrophic event; the ship *IS* sinking, let's not worry about the dinner menu. The immediate consequence must be that the application terminate as quickly as possible simply because the run-time can no longer guarantee that the internal datastructures are in a reliable state. This is even more critical if the CLR itself ran out of memory or detected a bug within itself. In that case, neither the user data nor the integrity of the application stack can be authenticated. The offending application must go, along with all the other spoilt apples related to the application such as cache. For this same reason code should never attempt to catch all exceptions or memory exceptions. Some exceptions such as memory exhaustion and stack overflows should be allowed to kill a program for that very reason. Additionally, code running on a webserver should run in an application pool within an app domain to prevent the entire webserver from going down with the errant program. For a complete discourse on exceptions, see Jeffrey Richters' applied framework programming SignatureRegards, Alvin Bruney [ASP.NET MVP] Got tidbits? Get it here... http://tinyurl.com/3he3b > > Also, if an > > OutOfMemoryException occurs anywhere in the worker process, the cache [quoted text clipped - 125 lines] > > > > > "Introduction to Production Debugging for .NET Framework > Applications" http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/ > > > > > DBGch01.asp > > > > > [quoted text clipped - 14 lines] > > > > > This posting is provided "AS IS" with no warranties, and confers no > > > > rights. This doesn't make sense. Are you suggesting that if the cache is expiring items due to memory pressure, then the entire application and its data is suspect? That is, the expiration due to memory pressure is really a non-reason; if you're at that state, you're beyond repair? What good is an LRU cache that doesn't drop items effectively/efficiently when it's out of room? j > > > Also, if an > > > OutOfMemoryException occurs anywhere in the worker process, the cache [quoted text clipped - 174 lines] > > > > > > "Introduction to Production Debugging for .NET Framework > > Applications" http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/ > > > > > > DBGch01.asp > > > > > > [quoted text clipped - 16 lines] > no > > > > > rights. > Are you suggesting that if the cache is expiring items due to memory > pressure, then the entire application and its data is suspect? No, read my post again. It says in the event of an out of memory exception. Obviously, if you haven't gotten to that point as in the case of memory pressure then the comments don't apply but you cannot expect to clean up cache after an out of memory exception was thrown which is what i was replying to. > > > > Also, if an > > > > OutOfMemoryException occurs anywhere in the worker process, the cache > > > should > > > > be cleared immediately The memory exception has already been thrown. Worrying about cache and what it contains is an excercise in futility since what the cache contains is not guaranteed to be valid. When an exception of this type occurs it is already to late. SignatureRegards, Alvin Bruney [ASP.NET MVP] Got tidbits? Get it here... http://tinyurl.com/3he3b > > This doesn't make sense. [quoted text clipped - 210 lines] > > > > > > > "Introduction to Production Debugging for .NET Framework > > > Applications" http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/ > > > > > > > DBGch01.asp > > > > > > > [quoted text clipped - 17 lines] > > no > > > > > > rights. Way back in this thread (paraphrasing): Why would we see an OutOfMemory exception when there are lots and lots of unpinned cache objects that could be collected? E.g., we have likely 400 MB of (small, unpinned) cache objects, and yet we see OutOfMemory exceptions. Shouldn't the cache effectively be 0 MB before seeing OutOfMemory? j > > Are you suggesting that if the cache is expiring items due to memory > > pressure, then the entire application and its data is suspect? [quoted text clipped - 249 lines] > > > > > > > > "Introduction to Production Debugging for .NET Framework > > > > Applications" http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/ > > > > > > > > DBGch01.asp > > > > > > > > [quoted text clipped - 19 lines] > > > no > > > > > > > rights. I've been testing the premise of your response for the last hour or so (instead of playing halo/xbox :-( using OP's modified code to include a cache callback and a button to control memory allocation. From what i've seen the cache is being scavenged. I've modified the code a bit to test whether or not the cache scavenging was being overrun with requests. It does seem to be so. That is, the OP's code is so tight that scavenging cannot keep up with memory allocation resulting in an overrun or a worker process recycle. I let the thread sleep for 10 milliseconds per iteration, and the worker process recycle was significantly delayed. That may be one thing for OP to look at in his memory exhaustion bug. It's difficult for me to create a memory exhaustion condition on my machine because i have 1gig of ram. I conjecture that, had the process not been recycled it would have run out of memory so I make the assumption that worker process recycling was a substitute for an out of memory condition in my case. review a portion of my code: // int count = 100000; //// int blocksize = 1000000; // // for(int n=0; n < count; n++) // { // string key = DateTime.Now.ToString(); // CacheTest.Global.obj = new byte[1000000]; // } int count = 100000; int blocksize = 10000; for(int n=0; n < count; n++) { System.Threading.Thread.Sleep(10); string key = "cacheitem_" + n; object obj = new byte[blocksize]; HttpContext.Current.Cache.Insert(key, CacheTest.Global.obj, null, DateTime.Now.AddSeconds(2), Cache.NoSlidingExpiration, CacheItemPriority.Normal, Global.onRemove); //Cache[key] = obj; time for halo now SignatureRegards, Alvin Bruney [ASP.NET MVP] Got tidbits? Get it here... http://tinyurl.com/3he3b > > Way back in this thread (paraphrasing): [quoted text clipped - 47 lines] > > > > > > "Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message > > > news:OfZgUFN9DHA.1596@TK2MSFTNGP10.phx.gbl... > > > > > > Also, if an [quoted text clipped - 235 lines] > > > > > > > > > "Introduction to Production Debugging for .NET Framework > > > > > Applications" http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/ > > > > > > > > > DBGch01.asp > > > > > > > > > [quoted text clipped - 19 lines] > > > > no > > > > > > > > rights. Hi, We have the same issues happening with our site, and have alieviated it somewhat by giving each website it's own application pool and two or three workers to share the load. This does *not* fix it, but it does reduce the frequency of the errors and increase stability. I was wondering if you ever came up with a solution that fixed this little problem? Thanks, Lance --- Hi, Jason Colins was nice enough to let me know how to treat this problem - Here is a copy of the email he sent me, composed by Chris Chan, one of Jason's collegues: Initially, we had 2GB ram, no limit to max used memory(private bytes) and max virtual memory(virtual byte). During that time, we got period of outofmemoryexceptions about 1 or 2 times per day and we had to manually recycle the app pool or IIS. At that time, we only measure the used memory(stay around 800mb - 1GB) and we have 2GB ram, so we wondered why still out of memory even had 1GB of ram free. Next step, we applied 800mb limit to max used memory. During that time, we still got outofmemoryexception, but not that often. But, the app pool was recycled more often. Then, we also set the max virtual memory to 1.2 GB, had outofmemoryexception more often. So, we believe the virtual address was not enough in our web application, and we believe this is actually due to the high utilization of caching. So, finally, we add another gig of ram to 3GB, turn on the 3GB/switch and increase the max used memory to 1.8 GB and virtual memory to 2.4 GB as suggested by the following article. After that, no more outofmemoryexception and is true Gung Ho! Since that I have been monitoring the Private Bytes and Virtual Bytes of the w3wp.exe process. Private Bytes stay around 800mb - 1GB which is similar what we had initially. However, virtual bytes is able to climb up around 2GB(without outofmemoryexception) and it will be dropped back to around 1.5GB suddenly. This make us believe the memory management(or garbage collector) is able to do its job in the good enough address space and timeframe. " . tests have shown that "Process\Virtual Bytes" is often larger than "Process\Private Bytes" by no more than 600 MB. This difference is due in part to the MEM_RESERVE regions maintained by the GC, allowing it to quickly commit more memory when needed. Taken together this implies that when "Process\Private Bytes" exceeds 800 MB, the likelihood of experiencing an OutOfMemoryException increases. " Overall, monitor Private Bytes and Virtual Bytes and adjust those limits, because the GC is using them as reference to do it job. Try to understand the memory requirement of your app, if it is still climbing up high, the chance for memory leaking in the app is high. Ref: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/mon itor_perf.asp I hope this help you and make sure you read the article which is helpful. Chris C. The linked article that Chris Chan refers to is quite good. I found some of the concepts a real eye-opener on how to optimize pages for ASP .NET. > Hi, > > We have the same issues happening with our site, and have alieviated it somewhat by giving each website it's own application pool and two or three workers to share the load. This does *not* fix it, but it does reduce the frequency of the errors and increase stability. > I was wondering if you ever came up with a solution that fixed this little problem? > [quoted text clipped - 4 lines] > > Our newsgroup engine supports Post Alerts, Ratings, and Searching. > If you want to expand this machine with 2GB more RAM, you don't need a OS > upgrade or registry switches. Windows server 2003 can handle these staff > for us. I have found seemingly conflicting information on MSDN. These 2 articles in particular seem to make the >2GB RAM issue muddy. Luke, can you please comment? (The first article pertains to SQL Server, but it talks a lot about general Windows memory issues.) http://msdn.microsoft.com/data/default.aspx?pull=/library/en-us/dnsqldev/html/sq ldev_01262004.asp Excerpt: "The /3GB boot option (available on the Advanced Server and Data Center editions of Windows 2000 and later) permits these default sizes to be changed. It allows a process's user mode address space to be expanded from 2GB to 3GB at the expense of the kernel mode address space (which is reduced from 2GB to 1GB). In Windows parlance, this facility is known as application memory tuning or 4GB tuning (4GT). You enable application memory tuning by adding /3GB to the appropriate line in the [operating systems] section of your BOOT.INI. Note Windows XP and Windows Server 2003 introduced a new boot option, /USERVA, to be used in conjunction with /3GB that allows a finer degree of control than /3GB alone." http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/mon itor_perf.asp Excerpt: "There are a couple things to consider: First, the likelihood of experiencing an OutOfMemoryException begins to increase dramatically when "Process\Virtual Bytes" is within 600 MB of the virtual address space limit (generally 2 GB), and secondly, tests have shown that "Process\Virtual Bytes" is often larger than "Process\Private Bytes" by no more than 600 MB. This difference is due in part to the MEM_RESERVE regions maintained by the GC, allowing it to quickly commit more memory when needed. Taken together this implies that when "Process\Private Bytes" exceeds 800 MB, the likelihood of experiencing an OutOfMemoryException increases." I really hope to use lots of RAM in my ASP.NET cache, but am confused by these articles and the steps to take to set it up. Any info would be appreciated, j > Hi Jason, > [quoted text clipped - 27 lines] > (This posting is provided "AS IS", with no warranties, and confers no > rights.) Hi Jason, It has been a long discussion. Please let me make a summary of the points here. To answer your questions, first of all yes the ASP.NET caching mechanism is designed in such a way that the runtime would try to clear the cache when it is detected that the memory consumption is approaching the specified limit, so as to prevent any OutOfMemroyExceptions from being thrown. It is recommended that you limit the maximum allowed memory size to 60% of your physical memory but no more than 800MB. If you have /3GB enabled with the OS and you are using .NET Framework 1.1 (1.0 does not support /3GB), then you can use more memory (1.2~1.8G) stably for ASP.NET. If you specify a limit beyond that number, system performance or stability may degradate. If you set the memory limit beyond the recommended numbers, basically it would not be a race condition or sth. like that to cause OutOfMemoryException. When the process memory consumption is beyond 800MB (without /3GB) it would start to experience that kind of exceptions because of the memory fragmentation in the system. If you set the limit as recommended, then there is a slight possiblility of a race conditioin as you guessed, because the ASP.NET runtime checks the system stats at a fixed interval and during that if you allocates a large amount of memory it could cause OutOfMemoryExceptions to be thrown before the runtime had an opportunity to expunge the cache items. Once an OutOfMemoryException is thrown, the integrity of the data structures inside a process could no longer be guaranteed, so all kinds of exceptions could begin to surface. At this point, typically the best thing to do is recycle a process as soon as possible. A good reference is listed as below: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html /monitor_perf.asp?frame=true The Large Object Heap issue Alvin mentioned, was that in .NET Framework once a large object was released, the virtual memory would not be returned to the operating system, though it could be used for future large objects. This meant the large object heap would never shrink in terms of reseaved space, and this would cause memory problems. In .NET Framework 1.1, this problem has been taken care of. Since you were mentioning Windows Server 2003 and IIS 6 I guess you were using .NET Framework 1.1 as well so this would not be a problem. Based on the OutOfMemoryExceptions problems we've seen, more than often the exceptions were not caused by uncleared caches, but that in the process there were large amounts of objects that had root references from all kinds of places that rendered them un-collectable by the GC. Fixing those references fixes the OutOfMemoryException. By the way, the OutOfMemoryException does not contain a stack trace because it is pre-allocated when the CLR initializes, considering that when the application is running out of memory it could also be for the exception object creation itself to fail. Also preallocated are an ExectuionEngineException and a StackOverflowException. Please feel free to let us know if the above explanation does not address your concerns. Regards, Xiao Xie Microsoft Corporation This posting is provided "AS IS" with no warranties, and confers no rights. > In .NET Framework 1.1, this > problem has been taken care of. nope, it's still there. Use OP's code and add another button to do GC.Collect(). Watch the aspnet worker process, the memory size does not fall. It should. Put code to unload the app domain, the memory will be reclaimed by the OS and the memory drops. SignatureRegards, Alvin Bruney [ASP.NET MVP] Got tidbits? Get it here... http://tinyurl.com/3he3b > Hi Jason, > [quoted text clipped - 29 lines] > > A good reference is listed as below: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html > /monitor_perf.asp?frame=true > [quoted text clipped - 27 lines] > > This posting is provided "AS IS" with no warranties, and confers no rights. Alvin, It looks like we are talking about two different issue here. The GC heap is process wide and not AppDomain wide, so if it were the problem I was talking about, Large Object Heap space reservation issue, even unloading an AppDomain would not help. Hope that makes sense. Regards, Xiao Xie Microsoft Corporation This posting is provided "AS IS" with no warranties, and confers no rights. true SignatureRegards, Alvin Bruney [ASP.NET MVP] Got tidbits? Get it here... http://tinyurl.com/3he3b > Alvin, > [quoted text clipped - 10 lines] > > This posting is provided "AS IS" with no warranties, and confers no rights. Xiao, this has been bugging me. If it's not VLO, then why does the worker process memory allocation keep climbing? Is there another bug? And why does it return to normal after a GC collect? SignatureRegards, Alvin Bruney [ASP.NET MVP] Got tidbits? Get it here... http://tinyurl.com/3he3b > true > [quoted text clipped - 15 lines] > > This posting is provided "AS IS" with no warranties, and confers no > rights. Hi, Thanks for your feedback. I must say that I still find it very unfortunate that you obviously can not use the Cache object without running the risk of bringing the ASP.NET process down. IMO the Cache object should have been much more tightly integrated with the .Net memory management code, so that memory could be freed when neeed. At the very least, the Cache should be more agressive about discarding members when memory is running low. Ideally, the Cache object would have a property/setting that allowed you to set the minimum amount of memory that must be available before the Cache is allowed to grow. Best, Ole > Hi Jason, > [quoted text clipped - 29 lines] > > A good reference is listed as below: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html > /monitor_perf.asp?frame=true > [quoted text clipped - 27 lines] > > This posting is provided "AS IS" with no warranties, and confers no rights.
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.