Performance Problems with your SCOM Console? This 'Might' Help....

My good friend Marnix has just blogged a very interesting post about a really slow performing SCOM console issue that he was having at one of his customer sites.

After a lot of searching to try and resolve the issue, he came across some information about editing the default 'Max Degree of Parallelism' setting inside the SQL instance that was hosting the SCOM databases. When he modified this SQL setting, the difference in performance of the SCOM console was HUGE! He even had staff at the customer site come up to him to see what he had changed because the difference in performance was so noticeable!

Now halt for just a second!

Before you rush off and go back to all your slow performing consoles and change the 'Max Degree of Parallelism' setting on every SQL server that your customers run SCOM on, just take note of some interesting points that Marnix and a few other SCOM 'enthusiasts' (i.e. MVP's and Microsoft staff) have been having offline about this topic in the last day or so....

• Some MVP's modified this setting and encountered performance gains.
• Other MVP's made the change and saw either no difference, or even a drop in performance of the SCOM console.
• A very well respected Microsoft employee working in the SCOM space also chipped in with his thoughts and made some interesting observations about how modifying 'Max Degree of Parrallelism' in the same way that each MVP saw gains in their console performance SHOULD NOT make any difference whatsoever!
• Another point was also made that, modifying this setting 'MIGHT' help with performance when using HyperThreading on VMware with CPU Gang Scheduling.

So, taking all these points into account, my recommendation is to have a good read of Marnix' post here...

http://thoughtsonopsmgr.blogspot.ie/2014/12/scom-2012x-console-on-steroids-try-mdop.html

Then make your own judgement call on whether or not you modify the setting.

My view on this is that if you're already having bad SCOM console performance issues, then you've got nothing to lose by first bench-marking how long it takes you to open the console and perform certain tasks, then making the change to SQL and comparing the new performance load times with their originals. If you see much of a difference for the better, then you could be on to a winner - if not, then just change the setting back to it's default value of '0' and you're back to where you started with no harm done!