High Memory – Service Manager


I’ve recently been able to resolve an on-going issue we have experienced since implementing Service Manager in our organisation. Initially we had 2012 R2, with multiple rollup updates and then upgraded to 2016, so the issue is not specific to a particular version.

Throughout the day we were seeing spikes to 100% memory which would drop back down. Then occasional the memory would stay at 100% for an hour or more at a time. This made the Service Manager console unusable for our Service Desk analysts. The workaround was the restart the System Center Data Access Service every time the memory was maxed out.

The Fix

It turns out this has always been related to a particular view that our analysts were viewing in the Service Manager console and Cireson portal. We know that views can cause slowness when the wrong classes are used (more on that here), however we’d never tied these issues together. The memory would be stuck at 100% even after the view had loaded, so it didn’t make sense.

After some memory dumps and log files had been analysed by Microsoft it was found that a view which was used to view calls that had been resolved in the last 12 hours was the cause. The view in question was of the class Incident (Advanced).

I need to do some further testing here, to see if I can replicate the issue when creating a view using a relative time filter when Incident (Advanced) is used, or if it was just the fact that the view was of the wrong class.


In short, I would always make sure to use a class for your views that doesn’t require so much overhead. We tend to use Incident (Affected User, Assigned User) or Incident (Typical) as these are much quicker to load. I’ve since recreated any Incident (Advanced) views with this instead.