Hi Kevin Thanks for the info.
My first thought was that the server is out of resources and SCOM can't cope, and so it appears to be hogging resources. The cluster has 5 SQL instances, nothing else. Yes these are virtual servers, I requested that the owners of the servers get more CPU when this started. The fact that the issue follows one particular instances points to possible heavy resource utilization by that instance, however I wasn't able to explain the heavy usage of monitoringhost, other than it appears to be hogging, but is rather under strain. The instance has 3 DB's in addition to the system DB;s, and 15 jobs, but the main DB is a heavy utilized DB, used for receiving and sending a large amount of transactions for backoffice capturing. Your reply seems to substantiate my thoughts. The other cluster I mentioned with the AG also has virtual nodes with the same CPU count, I suspect the same applies. I'll also look into the SQL MP. Thanks Gareth From: [email protected] [mailto:[email protected]] On Behalf Of Kevin Holman Sent: 14 December 2016 05:27 PM To: [email protected] Subject: [msmom] RE: MonitoringHost.exe and High CPU Are there a high number of DB's in this specific instance, or anything else making it unique? I'd start by updating to the latest SQL MP and see if the problem is resolved, there are significant changes from 6.6.4 which is a year old at this point. Beyond that, I'd focus on identifying which scripts are creating the resource utilization issues via ETL tracing. Are these clusters running 5 instances of SQL and only two CPU's? Are these VM's? It is quite possible the host is oversubscribed are two virtual CPU's is not enough. For example - in your second cluster node you consider "good" I see RHS.exe taking up a lot of CPU which isn't normal, and I see the SQL 2014 filegroup discovery script running..... which you should not be able to see running for long at all, or it is stuck or taking too long..... likely due to resources as well. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Gareth Miles Sent: Wednesday, December 14, 2016 6:09 AM To: [email protected]<mailto:[email protected]> Subject: [msmom] MonitoringHost.exe and High CPU Hi I have a few SQL servers that get high(99% Total) CPU usage by the monitoringhost service. I've done a detailed investigation on one of the SQL clusters I have a 2012 SP1 UR 10 SCOM environment with one management group. The SCOM agents on the nodes of this cluster connect to a gateway which connects to the management server. SQL MP version is 6.6.4.0, which I believe has an issue with some PowerShell rules/monitors. The Cluster in question has 5 x SQL 2014 instances on 2 x WS 2012 R2 nodes. The high CPU follows one particular SQL instance, so I have the other 4 on one node, and this instance on the other node, and CPU is maxed. I've followed this post and disabled the 4 Rules & monitors for all versions of SQL, and forced the override. https://blogs.technet.microsoft.com/systemcenterpt/2016/04/08/opsmgr-2012-r2-monitoringhost-exe-causes-100-or-high-cpu-usage-on-windows-2008-sp2-or-r2-servers-after-importing-sql-mp-6-6-4-0-or-6-6-2-0/ I've noted this hotfix to address MSXML 6.0, however there's no mention of it being supported for WS 2012 R2 so I'm hesitant to run it as the Cluster is a production cluster. Any advice in this regard would be appreciated. https://support.microsoft.com/en-za/kb/968967 I've followed this post, and adjusted the settings, I was mainly looking at the PowerShell settings, thinking back to the SQL MP PowerShell issues. http://www.opsman.co.za/scom-not-all-objects-on-a-server-are-discovered-managed/ I've confirmed that AV exclusions are in place for the Health Service State folder and its contents. The screen shot shows the monitoringhost using 46.5%, and the SQL instance using 25.4% of CPU, with total CPU maxed. [cid:[email protected]] The CPU of the monitoring host jumps around from 20% up to 50%, the total CPU doesn't drop below 97%. This shows the CPU with the agent stopped. [cid:[email protected]] This server should have enough resources to manage a single instance and the SCOM agent, see the specs below. [cid:[email protected]] This is the second node with 4 SQL instances running and the agent running. [cid:[email protected]] I'm at a loss at what else to check. Is there any way of telling what the monitoring host is running? Could I use the trace tool in some way, I find it generally has more info then I can track, any tips here would help. I have a second cluster that has a single SQL 2016 AG on 2 x WS 2012 R2 nodes. Here the primary node is stable and the secondary node gets maxed out CPU with the monitoringhost also sitting around 45% CPU. I can't explain why the monitoring host would use up to 50% of the total CPU, any help would be appreciated. Kind Regards [ITServiceAssurance_Logo (2)] Gareth Miles System Center Technical Lead Phone: +27 31 580 1582 Mobile: +27 83 648 8559 ________________________________ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Furthermore, the information contained in this message, and any attachments thereto, is for information purposes only and may contain the personal views and opinions of the author, which are not necessarily the views and opinions of the company. ________________________________ ############################################################################################# The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Furthermore, the information contained in this message, and any attachments thereto, is for information purposes only and may contain the personal views and opinions of the author, which are not necessarily the views and opinions of the company. #############################################################################################
