maximizing memory available for cache
Jason Collins
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
MSFT
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
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
Jason Collins
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
"MSFT" <luke...@online.microsoft.com> wrote in message
news:wo6rPnt5...@cpmsftngxa07.phx.gbl...
Jason Collins
> 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/sqldev_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/monitor_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
"MSFT" <luke...@online.microsoft.com> wrote in message
news:wo6rPnt5...@cpmsftngxa07.phx.gbl...
MSFT
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.
Jason Collins
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
"MSFT" <luke...@online.microsoft.com> wrote in message
news:sbdjZij6...@cpmsftngxa07.phx.gbl...
MSFT
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?
Jason Collins
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
"MSFT" <luke...@online.microsoft.com> wrote in message
news:RCA%238376D...@cpmsftngxa07.phx.gbl...
MSFT
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.
Jason Collins
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
"MSFT" <luke...@online.microsoft.com> wrote in message
news:l2UbOyH7...@cpmsftngxa07.phx.gbl...
Alvin Bruney [MVP]
being returned every once in a while? Do you know? Can you check. Anything
over 30,000 rows as a ballpark.
--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/3he3b
"Jason Collins" <jcollin...@point2.com> wrote in message
news:OBb5ECM...@tk2msftngp13.phx.gbl...
Jason Collins
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
"Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message
news:uLU0$JP7DH...@TK2MSFTNGP10.phx.gbl...
Alvin Bruney [MVP]
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.
--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/3he3b
"Jason Collins" <jcollin...@point2.com> wrote in message
news:%2353ympP...@TK2MSFTNGP10.phx.gbl...
Yan-Hong Huang[MSFT]
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.
Ole Thrane
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
"Yan-Hong Huang[MSFT]" <yhh...@online.microsoft.com> wrote in message
news:Xbaglvt7...@cpmsftngxa07.phx.gbl...
Alvin Bruney [MVP]
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.
--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/3he3b
"Ole Thrane" <o...@anon.org> wrote in message
news:eF0f8Lh8...@TK2MSFTNGP11.phx.gbl...
Ole Thrane
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
"Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message
news:emVUEkl8...@TK2MSFTNGP11.phx.gbl...
Jason Collins
> 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
"Ole Thrane" <o...@anon.org> wrote in message
news:OfV$LnG9DH...@TK2MSFTNGP11.phx.gbl...
Alvin Bruney [MVP]
> > 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
--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/3he3b
"Jason Collins" <jcollin...@point2.com> wrote in message
news:eqxrdVM9...@TK2MSFTNGP09.phx.gbl...
Jason Collins
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
"Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message
news:OfZgUFN9...@TK2MSFTNGP10.phx.gbl...
Alvin Bruney [MVP]
> 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.
--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/3he3b
"Jason Collins" <jcollin...@point2.com> wrote in message
news:eEJn$cN9DH...@TK2MSFTNGP11.phx.gbl...
Jason Collins
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
"Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message
news:%23WRib7N...@TK2MSFTNGP09.phx.gbl...
Alvin Bruney [MVP]
(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
--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/3he3b
"Jason Collins" <jcollin...@point2.com> wrote in message
news:uh3c6NO9...@TK2MSFTNGP09.phx.gbl...
Xiao Xie [MSFT]
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
Alvin Bruney [MVP]
> 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.
--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/3he3b
"Xiao Xie [MSFT]" <xia...@online.microsoft.com> wrote in message
news:qXEUjvV9...@cpmsftngxa07.phx.gbl...
Xiao Xie [MSFT]
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.
Ole Thrane
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
"Xiao Xie [MSFT]" <xia...@online.microsoft.com> wrote in message
news:qXEUjvV9...@cpmsftngxa07.phx.gbl...
Alvin Bruney [MVP]
--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/3he3b
"Xiao Xie [MSFT]" <xia...@online.microsoft.com> wrote in message
news:tuBFEVg9...@cpmsftngxa07.phx.gbl...
Alvin Bruney [MVP]
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?
--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/3he3b
"Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message
news:u8qXsgq9...@TK2MSFTNGP10.phx.gbl...
lance
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
---
Posted using Wimdows.net NntpNews Component -
Post Made from http://www.DotNetJunkies.com/newsgroups Our newsgroup engine supports Post Alerts, Ratings, and Searching.
Lance
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/monitor_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.
"lance" <lance.keay@-NOSPAM-nospam.e-inbusiness.co.uk> wrote in message
news:#ZbHDD$mEHA...@TK2MSFTNGP11.phx.gbl...