Are you looking at the process virtual memory size or the working set size? These two will give quite a different picture of what your process is doing. (It's also sometimes a less than exact science interpreting this stuff, since measuring a process's memory use is not always that clear cut - if a process causes certain pages from system DLLs to be loaded in, is that part of its working set? Presumably, but what if it's not the only process in the system using those pages?.. You tend to end up with a total 'memory in use' figure that's substantially larger than the amount of memory you have.)
It is possible that your program really is sitting on that much memory in a way that the garbage collector can't do anything with. Alternatively, it's possible that the garbage collector found all your free memory, but elected not to return that memory to the OS when you called System.GC.Collect, because it saw that there was plenty of free memory in the system, so there was no point wasting CPU cycles to free up memory that (a) isn't needed by anything else and (b) might well be needed again by this process. One way to find out how much memory your process is really using is to use the performance monitor - it has some GC measurements that can be helpful. Or you can run it through the .NET Allocation Profiler: http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=3 6a3e666-6877-4c26-b62d-bfd7cb3154ac This will show you in detail how your program is using memory. It takes a little learning to use this tool effectively, but it's well worth the effort. -- Ian Griffiths DevelopMentor -----Original Message----- From: Paulo Jorge F. Sacramento [mailto:[EMAIL PROTECTED] I hope that's true. I've had the same problem with my services, which are written in C#. Mine are even worse. I have one that takes up 23 MB. It's using Remoting, AppDomains, Threads, XML, some Reflection also, and other things, but nothing that I'd think would occupy so much memory. The reason I'm not so sure about your explanation is that I've tried explicitly calling the GC (with System.GC() or something like that) and it didn't do much. If what you say is right, wouldn't it be expectable that an explicit call to the GC would release a probably big chunk of memory? By the way, I've also had a case with a much simpler service that occupied about 6 or 7 MB at the beggining of execution, but that after a while would occupy only a few KBs. It was "sleeping" most of the time and did a very rare periodical check. I guess the O.S. together with the GC take care of releasing all unneeded resources. This also suggests that .Net services have an heavy "start-up penalty". Any thoughts on this? Paulo Sacramento On Wed, 30 Jul 2003, Griffiths, Ian wrote: > .NET processes will tend to grow to what looks like an alarmingly large > size unless there is a reason for them to shrink. The CLR does actually > keep track of the amount of memory being used system-wide, and if other > processes start to demand more memory, the CLR will trigger a garbage > collect in your process, reducing the amount of memory that it is using. > > So the large-looking memory consumption isn't usually an issue. If > anything else in the system starts to need that memory, the CLR will > give it back. > > IDispose doesn't have any bearing on this. IDispose has nothing to do > with memory allocation, it's just about other resources. The fact that > your memory usage stays constant at 18MB indicates that you're not > leaking resources. > > If it was forever creeping upwards, then that would be something to > worry about. But 18MB is fairly normal. > > > -- "We live in a society exquisitely dependent on science and technology, in which hardly anyone knows anything about science and technology." Carl Sagan
