.Net 2.0 memory usage

[Joe K]

I ported a .Net service from 1.1 to 2.0. In .Net 1.1, the total private
bytes for this service ran around 40MB. In .Net 2.0, the same service has
total private bytes of around 140MB. I then ran our service under a memory
debugger, and we have a total of 34 MB allocated on the heap.

Anyone have any ideas as to where the extra 100MB is going in .Net 2.0?

Joe

 

[Joe K]

So check this out:
- .Net memory # Bytes in all Heaps = 1.8 MB
- .Net memory # Total committed bytes = 3.3 MB
- .Net memory # Total reserved bytes = 33.9 MB
- Private bytes = 139.6 MB

Huh? This make any sense to anyone?

 

[ForrestPhoto]

Huh? This make any sense to anyone?

No. What does your service do?

 

[Joe K]

I have a little more information. The difference appears to be related to
System.Threading.Thread. If I build a standalone .Net service in .Net 2.0
that starts 100 threads, I will see ~110 MB of memory allocated in private
bytes to this process. The same code on .Net 1.1 results in 7 MB of memory
in private bytes.

If anyone can explain this, I am very interested in understanding this.

Thanks.

Joe

 

[Henning Krause [MVP - Exchange]]

Hello,

usually, every thread has a stack size of 1 MB... but AFAIK, that has not
changed from 1.1 to 2.0. So I would guess, the .NET 2.0 behavior is
correct. I'm not sure why a .NET 1.1 software would behave other.

Albeit from this: Why are you using 100 threads? Seem very much to me...
either, most of your threads wait most of the time, or you'll have many
thread context switches...

Best regards,
Henning Krause

 

[Joe K]

My theory is that the .Net 2.0 behavior is correct too - I just can't
explain what I see in .Net 1.1

Is it possible that .Net 1.1 used the Win32 thread pool in some way,
resulting in the memory allocated for a threads to be counted as shared
memory, and thus not being counted in private bytes?

I used 100 as an example. Our thread pool shrinks/grows based on demand.

Joe

 

[Henning Krause [MVP - Exchange]]

Hello,

the .NET ThreadPool is built ontop on the Win32 threadpool in both versions.

But if you create 100 threads yourself, the ThreadPool is not used...

Best regards,
Henning Krause

 

[Joe K]

Okay, then I can't explain it. Go ahead and try it though. The below code
in .Net 1.1 reports 7MB for private bytes, but 111MB in 2.0.

namespace TestService
{
public partial class Service1 : ServiceBase
{
public Service1()
{
InitializeComponent();
}

protected override void OnStart(string[] args)
{
for (int i = 0; i < 100; i++)
{
Thread thread = new Thread(Service1.Run);
thread.Start();
}
}

protected override void OnStop()
{
// TODO: Add code here to perform any tear-down necessary to
stop your service.
}

protected static void Run()
{
while (true)
{
Thread.Sleep(1000*10);
}
}
}
}

 

[Chris Mullins [MVP]]

If nothing else, you're creating 100 threads. Each thread requires 1 Meg of
stack space from your Working Set. That's 100 Megs already.

 

[Joe K]

Create 10, 20 or 100 threads in your test, and the result will still be the
same: thread memory is not counted in private bytes in 1.1, but is in 2.0.
I'm just wondering why? Not sure I understand the fixation on the # of
threads - that has nothing to do with my question.

Joe

 

[Chris Mullins [MVP]]

The point is that your app, with 100 threads, SHOULD be consuming 100+ megs
of memory. This is correct, and not a problem.

If the .Net 1.1 app reported less, then it was either 1) A bug somewhere in
the memory reporting, or 2) You're looking at the wrong counters.

You could try the "resize the working set" trick if you want:
http://www.coversant.net/Coversant/Blogs/tabid/88/EntryID/4/Default.aspx

It won't actually change anything, but the numbers being reported in Task
Manager will change.