Monitor memory usage, redux

[nrusch]

I had to delete tens of thousands of bogus job errors that had continuously accumulated due to slave startup bugs this morning, and it blew my Monitor’s memory usage up to about 1,300 MB. I ran Force Garbage Collection to see what would happen, and the Monitor echoed this to the console:

Before Collection: [memory usage] 122.348MB / 0.000 Bytes After Collection: [memory usage] 95.562 MB / 0.000 Bytes
My monitor is still using over a gig of RAM (although it seems to drop in chunks every couple of minutes), so I’m curious why the Monitor thinks its footprint is so svelte. I realize that running anything in a memory-managed environment complicates a process’ ability to track its own memory usage, but the discrepancy between what it thinks it’s using and what is actually in use by the process is pretty staggering. Is the .NET GC really this lazy, or could this be a leak?

Thanks.

[rrussell]

I don’t think it’s a leak, since the memory is slowly getting cleaned up.

Can you run the following command on your machine and post the output?

mono -V

This prints out the mono version, but it also prints out the garbage collector it’s using. I believe mono 2.x defaults to the Boehm GC, while mono 3.x (which we’re now shipping with Deadline 7) uses the newer SGen GC. We have found the SGen GC to work much better, so you could always upgrade your mono installation since Deadline 6 works fine with mono 3.x.

Cheers,
Ryan

[nrusch]

Yeah, we’re using Mono 2.10 with the Boehm GC. The memory usage did eventually stabilize… at 772 MB. So it’s definitely still running fat.