Re: Pressuring GC to give up clean up memory.
- From: "Willy Denoyette [MVP]" <willy.denoyette@xxxxxxxxxx>
- Date: Wed, 16 May 2007 17:09:22 +0200
"Frank Rizzo" <none@xxxxxxxx> wrote in message news:eY8eK0llHHA.208@xxxxxxxxxxxxxxxxxxxxxxx
Nicholas Paldino [.NET/C# MVP] wrote:Frank,
Is the number you are seeing the only concern, or is the memory that is being consumed by your app having a measurable effect on other applications on the box?
Basically, the powers that be, decided that the app is going to be on the same box as the SqlServer2k5 64-bit, which consumes ungodly amounts of memory (compared to sqlserver2k, anyways). So the sum of my app and SQL Server is pushing up against the limits of physical memory. When it does cross that limit, things get really, really slow. When my app is idle for more than a certain amount of time, I try to dump the memory contents by setting the root object to null - but that does not seem to be having an effect.
If SQL Server is configured to consume exactly what it needs, and there is enough memory left to let your application run without the risk of excessive paging you are set, else you are in a world of pain, playing ticks with the GC won't help. Just face it, when there is memory pressure (that is, you have reached a certain threshold) because SQL needs more memory, the OS will ask your application (and others) to reduce it's working set, the CLR will trigger a full collection and the CLR's memory manager will return freed heap space (if any) to the OS, if the GC cannot release enough memory, the OS will simply trim your application's (and others) working set, by writing modified pages to the page file, until there is enough free memory to fulfill SQL's request. Whenever your application get's a chance to run again, it will "possibly" need to page-in the pages previously written to the page file, but to make this happen, the OS will need to trim the WS of SQL server, this is especially bad from a performance perspective, so your only options are:
- Reduce the memory consumption of your application, inspect your object hierarchies, are you using the most optimal container types, are you taking care of the growth algorithms of some of these containers, aren't you overusing OO paradigms?
- If your application runs as 64 bit application, recompile it as 32 bit (unless you need to address more than 2GB), 64 BIT applications are real memory hogs, especially managed applications.
- Add more memory to the box.
Willy.
.
- Follow-Ups:
- Re: Pressuring GC to give up clean up memory.
- From: Alvin Bruney [MVP]
- Re: Pressuring GC to give up clean up memory.
- References:
- Pressuring GC to give up clean up memory.
- From: Frank Rizzo
- Re: Pressuring GC to give up clean up memory.
- From: Nicholas Paldino [.NET/C# MVP]
- Re: Pressuring GC to give up clean up memory.
- From: Frank Rizzo
- Pressuring GC to give up clean up memory.
- Prev by Date: file transfer with sockets
- Next by Date: Re: how good is .NET's Random for making random numbers?
- Previous by thread: Re: Pressuring GC to give up clean up memory.
- Next by thread: Re: Pressuring GC to give up clean up memory.
- Index(es):
Relevant Pages
|
