locked
Console memory leak? RRS feed

  • Question

  • I've just installed all the pieces of SCSM and have just started fleshing out some things in the console.  I've noticed that as I use the console throughout the day the memory usage just keeps climbing on my PC.  Yesterday it went up to 1.4GB of ram used and the console became so sluggish it was pretty much unusable.  So I closed the console and reopened.  It started out fresh at about 130MB of ram used.  The same thing is happening today... the more I click around and use it the larger it gets.

    Is this a memory leak?  Is there a fix for this?  Anyone else having this problem or am I special?

    Friday, November 5, 2010 2:23 PM

Answers

  • Hi Gman,

    I think this is a known issue on currently version of SCSM, take a look:

    Service Manager Console Performance

    Performance of the Service Manager console is primarily affected by the number of forms your analysts typically have open and the amount of data retrieved by views. You should have a minimum of 2 GB of RAM for the computer where the Service Manager console is installed. If you have views that retrieve a large amount of data, you will need additional RAM. You should have at least a dual-core CPU for the computer where the Service Manager console is installed. Because the Service Manager console is an end user application, we recommended that you restart it if you see excessive resource consumption – the Service Manager console aggressively caches information in memory, which can contribute to overall memory usage.

    Source: http://technet.microsoft.com/en-us/library/ff461124.aspx

     

    Hope this helps.

    Regards,

     

    Cleber Marques

    Microsoft MVP & MCT | Charter Member: SCVMM & MDOP
    MOF Brazil Project: Simplifying IT Service Management
    My Blog | MOF.com.br | CleberMarques.com | CanalSystemCenter.com.br
    Saturday, November 6, 2010 10:03 AM

All replies

  • Hi Gman,

    I think this is a known issue on currently version of SCSM, take a look:

    Service Manager Console Performance

    Performance of the Service Manager console is primarily affected by the number of forms your analysts typically have open and the amount of data retrieved by views. You should have a minimum of 2 GB of RAM for the computer where the Service Manager console is installed. If you have views that retrieve a large amount of data, you will need additional RAM. You should have at least a dual-core CPU for the computer where the Service Manager console is installed. Because the Service Manager console is an end user application, we recommended that you restart it if you see excessive resource consumption – the Service Manager console aggressively caches information in memory, which can contribute to overall memory usage.

    Source: http://technet.microsoft.com/en-us/library/ff461124.aspx

     

    Hope this helps.

    Regards,

     

    Cleber Marques

    Microsoft MVP & MCT | Charter Member: SCVMM & MDOP
    MOF Brazil Project: Simplifying IT Service Management
    My Blog | MOF.com.br | CleberMarques.com | CanalSystemCenter.com.br
    Saturday, November 6, 2010 10:03 AM
  • Hi.

    We have also disvovered this in our management server with 8 vCPU's, 10GB ram, and loads of power:) To me it seems like it's not only related to only hardware. We tried to install the .NET Framwroks in it's "cumulative" releases. First .Net 1.1, then 2.0, 2.0, 3.5, and 4 as the last one. This seemed to have helped with the console mem leaks for some reason. I guess .NET are not 100% cumulative? I dont have the knowledge about the API's and code of those, so It's just my personal opinion and experience. We have tested it this way since RC, and can relate a small increase in perfomance as we do it this way. But Cleber do have a good point there as well:)

    Can you check this out? I would also like you to check wheter or not the SSP is on the MS, because that might drag down the overall performance of SCSM. Hope this helps a little.

    Cheers

    TM


    Best Regards Thomas Mortsell
    Wednesday, November 24, 2010 12:17 PM