DebugDiag help - IIS out of memory
in [IIS]
|
Prev: Win7 IIS did not get recognised
Next: ISAPI Extension on Exchange CAS (IIS) caused Mobile Devices to sto
From: Rune Wahle on 25 May 2010 02:47 Hi, I have a IIS apppool that gave me "out-of-memory" exceptions in ASP. I have debugdiag installed and did a full memory dump. It looks like heap framentation. Can anybody help to pinpoint exactly what causes this ??? Detected symptoms of high fragmentation in the following heaps in w3wp.exe__Shop5__PID__4352__Date__05_25_2010__Time_08_05_49AM__546__Manual Dump.dmp 0x00080000 (Default process heap - 99,91% Fragmented) 0x002b0000 (msvcrt!_crtheap - 89,20% Fragmented) 0x02a40000 (92,49% Fragmented) 0x03fa0000 (Microsoft Data Access Runtime MpHeap 11 - 76,24% Fragmented) 0x03fe0000 (Microsoft Data Access Runtime MpHeap 12 - 76,52% Fragmented) 0x04020000 (Microsoft Data Access Runtime MpHeap 13 - 90,98% Fragmented) Virtual Memory Summary Size of largest free VM block 1.024,00 KBytes Free memory fragmentation 97,14% Free Memory 34,95 MBytes (1,71% of Total Memory) Reserved Memory 1,46 GBytes (73,03% of Total Memory) Committed Memory 517,40 MBytes (25,26% of Total Memory) Total Memory 2,00 GBytes Largest free block at 0x00000000`0c050000
From: Brian Cryer on 25 May 2010 04:21 "Rune Wahle" <RuneWahle(a)discussions.microsoft.com> wrote in message news:CC919DC1-0331-4916-A0CC-161B30E4246C(a)microsoft.com... > Hi, > > I have a IIS apppool that gave me "out-of-memory" exceptions in ASP. > I have debugdiag installed and did a full memory dump. > > It looks like heap framentation. > > Can anybody help to pinpoint exactly what causes this ??? The only time I've had a problem like this was when allocating BIG chunks of memory (in my case for cutting up images at run-time). With .NET (don't know if this applies to classic ASP) memory requests for large chunks of memory come from the Large Object Heap (LOH) instead of the regular heap. The problem with the LOH is that it doesn't get defragmented (ugh), which means that you are guaranteed eventually to get an out of memory error. Whilst I'm tempted to say its bad design, I'm sure the designers had a reason for it at the time. Assuming that's the case then the only approaches I can suggest are: 1. Look at your memory allocation, are you creating any objects which individuall will occupy more than 85KB because those will come from the LOH and won't get defragmented. Can any of these be made smaller (i.e under the 85KB limit) so they will come from the regular heap instead. (Of course this assumes .NET so may not apply if you are using classic ASP) 2. Look at the application pool recycle settings. I would suggest ensuring that the maximum used memory setting is set (start at say half your RAM and go from there - try adjusting it down each time you hit your out of memory exception). The idea is to cause the application pool to recycle (and thus start a new instance) before you get to the point where you are running out of memory. 3. Ensure that each application (and in particular the application giving you problems) has its own separate/dedicated application pool. Hope this helps. -- Brian Cryer http://www.cryer.co.uk/brian
From: Rune Wahle on 25 May 2010 12:45 Hi Brian, Thanks for your reply. Do you know if the issue with big chunks > 85K also applies when you are sure that you destroy your objects after use ? (eg setting them to = nothing in ASP) ? Or will it still be fragmented? Do you know any debug tools or hints on how to debug this a bit more down in details in order to find out what fills the memory ? "Brian Cryer" wrote: > > "Rune Wahle" <RuneWahle(a)discussions.microsoft.com> wrote in message > news:CC919DC1-0331-4916-A0CC-161B30E4246C(a)microsoft.com... > > Hi, > > > > I have a IIS apppool that gave me "out-of-memory" exceptions in ASP. > > I have debugdiag installed and did a full memory dump. > > > > It looks like heap framentation. > > > > Can anybody help to pinpoint exactly what causes this ??? > > The only time I've had a problem like this was when allocating BIG chunks of > memory (in my case for cutting up images at run-time). With .NET (don't know > if this applies to classic ASP) memory requests for large chunks of memory > come from the Large Object Heap (LOH) instead of the regular heap. The > problem with the LOH is that it doesn't get defragmented (ugh), which means > that you are guaranteed eventually to get an out of memory error. Whilst I'm > tempted to say its bad design, I'm sure the designers had a reason for it at > the time. > > Assuming that's the case then the only approaches I can suggest are: > > 1. Look at your memory allocation, are you creating any objects which > individuall will occupy more than 85KB because those will come from the LOH > and won't get defragmented. Can any of these be made smaller (i.e under the > 85KB limit) so they will come from the regular heap instead. (Of course this > assumes .NET so may not apply if you are using classic ASP) > > 2. Look at the application pool recycle settings. I would suggest ensuring > that the maximum used memory setting is set (start at say half your RAM and > go from there - try adjusting it down each time you hit your out of memory > exception). The idea is to cause the application pool to recycle (and thus > start a new instance) before you get to the point where you are running out > of memory. > > 3. Ensure that each application (and in particular the application giving > you problems) has its own separate/dedicated application pool. > > Hope this helps. > -- > Brian Cryer > http://www.cryer.co.uk/brian > > . >
From: Brian Cryer on 26 May 2010 05:02
"Rune Wahle" <RuneWahle(a)discussions.microsoft.com> wrote in message news:6837A259-6428-4C1B-B242-204F992202BB(a)microsoft.com... > Hi Brian, > > Thanks for your reply. > > Do you know if the issue with big chunks > 85K also applies when you are > sure that you destroy your objects after use ? (eg setting them to = > nothing > in ASP) > ? Or will it still be fragmented? That's the problem. Big chunks (>85KB) come from the Large Object Heap and no they won't get defragmented whatever!! It will be garbage collected but not defragmented. > Do you know any debug tools or hints on how to debug this a bit more down > in > details in order to find out what fills the memory ? The following article might help: http://www.simple-talk.com/dotnet/.net-framework/the-dangers-of-the-large-object-heap/ Sadly, no, I dno't know of any tools which can help debug this :( That said, the first post at the bottom of the article I referred to indicates that you may be able to use windbg. Reading through the comments, it looks like its better (but not resolved) in .NET 4. -- Brian Cryer http://www.cryer.co.uk/brian > "Brian Cryer" wrote: > >> >> "Rune Wahle" <RuneWahle(a)discussions.microsoft.com> wrote in message >> news:CC919DC1-0331-4916-A0CC-161B30E4246C(a)microsoft.com... >> > Hi, >> > >> > I have a IIS apppool that gave me "out-of-memory" exceptions in ASP. >> > I have debugdiag installed and did a full memory dump. >> > >> > It looks like heap framentation. >> > >> > Can anybody help to pinpoint exactly what causes this ??? >> >> The only time I've had a problem like this was when allocating BIG chunks >> of >> memory (in my case for cutting up images at run-time). With .NET (don't >> know >> if this applies to classic ASP) memory requests for large chunks of >> memory >> come from the Large Object Heap (LOH) instead of the regular heap. The >> problem with the LOH is that it doesn't get defragmented (ugh), which >> means >> that you are guaranteed eventually to get an out of memory error. Whilst >> I'm >> tempted to say its bad design, I'm sure the designers had a reason for it >> at >> the time. >> >> Assuming that's the case then the only approaches I can suggest are: >> >> 1. Look at your memory allocation, are you creating any objects which >> individuall will occupy more than 85KB because those will come from the >> LOH >> and won't get defragmented. Can any of these be made smaller (i.e under >> the >> 85KB limit) so they will come from the regular heap instead. (Of course >> this >> assumes .NET so may not apply if you are using classic ASP) >> >> 2. Look at the application pool recycle settings. I would suggest >> ensuring >> that the maximum used memory setting is set (start at say half your RAM >> and >> go from there - try adjusting it down each time you hit your out of >> memory >> exception). The idea is to cause the application pool to recycle (and >> thus >> start a new instance) before you get to the point where you are running >> out >> of memory. >> >> 3. Ensure that each application (and in particular the application giving >> you problems) has its own separate/dedicated application pool. >> >> Hope this helps. >> -- >> Brian Cryer >> http://www.cryer.co.uk/brian >> >> . >> |