Ask a questionAsk a question
 

Proposed AnswerCPU Usage by SMSEXEC at Same Time

  • Wednesday, August 12, 2009 4:47 PMCody DeHaan Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Hello!

    Every day for 10-20 minutes, sometime around the 11:00 hour (yesterday 10:55-11:05, today 11:25-11:45), SMSEXEC eats 100% CPU on our SCCM server. SQL is not using much CPU at all during this time, so it appears that the culprit is something within SCCM. I do not have any collections set to update, no AD discoveries happening at that time so far as I can tell, nor any WSUS synchronizations. How can I track this down?

    Additional information is that Process Explorer reveals the thread to be a baseutil.dll _NewThreadWrapper. Not sure what that means. Also, AD discoveries are set to run every 24 hours starting at 12AM... I'm assuming that means they'll run at that rough time, but perhaps not?

    Thanks in advance!

All Replies

  • Wednesday, August 12, 2009 5:13 PMSherry KissingerMVPUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    ConfigMgr logs are very verbose.  Have you checked or monitored the logs in your <installed location>\logs folder?


    Standardize. Simplify. Automate.
  • Wednesday, August 12, 2009 6:02 PMCody DeHaan Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    I have done my best to poke around, but after looking through all of the files that seemed to be updated recently while it's occuring, there doesn't seem to be anything raising any red flags for me.

    Do you have any suggestions of files to look through specifically?
  • Friday, August 14, 2009 1:12 PMCody DeHaan Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    After loading all the logs into Trace32 and doing some filtering, the one thing I noticed was this:

    Done with job queueing. SMS_INVENTORY_DATA_LOADER 8/13/2009 2:20:12 PM 3244 (0x0CAC)
    Blocking until completion. SMS_INVENTORY_DATA_LOADER 8/13/2009 2:20:12 PM 3244 (0x0CAC)
    Done blocking until completion. SMS_INVENTORY_DATA_LOADER 8/13/2009 2:46:25 PM 3244 (0x0CAC)
    No more machine MIFs to be processed, terminating thread SMS_INVENTORY_DATA_LOADER 8/13/2009 2:46:25 PM 3244 (0x0CAC)
    Shutting down Machine Writer. SMS_INVENTORY_DATA_LOADER 8/13/2009 2:46:25 PM 3244 (0x0CAC)
    Finished processing 1 MIFs SMS_INVENTORY_DATA_LOADER 8/13/2009 2:46:30 PM 3244 (0x0CAC)

    I see it did a "Blocking until Completion" at 2:20, and then "Done Blocking until Completion" at 2:46, which matches the times I'm seeing for the CPU spike.

    I'm going to do some more looking, but what might be the cause of this? We only have two clients (test machines) attached to the server right now -- hopefully them sending inventory doesn't cause this??
  • Friday, August 14, 2009 5:26 PMSherry KissingerMVPUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    It's possible that 1 of those boxes is reporting a lot -- a ton-- of data.

    There's a few ways to capture the mif file from a client, so you can see what's inside.  Once we know what's inside, we can make decisions about how to remediate.

    Since you "only" have two clients, and you should be able to tell which client sent that 2:20pm inventory, you can follow these steps to grab the mif, so you can look at it in notepad:

    http://myitforum.com/cs2/blogs/rickym61/archive/2009/01/09/sms-2003-logging.aspx


    Standardize. Simplify. Automate.
  • Friday, August 14, 2009 5:36 PMDonnie Taylor Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    You might also check your Site Maintenance Tasks - see if any are set to run at 11.  Depending on the task and how often you run it, they can definately eat some CPU cycles.
  • Monday, August 17, 2009 1:03 PMCody DeHaan Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    I was unable to find any Site Maintenance Tasks set to run at that time.

    I did, however, realize that this seems to happen when I restore my test VM and reinstall the SCCM Client. It looks like the new set of inventory has to overwrite the old set, and that perhaps that's making SCCM choke a bit. It's a little unnerving to me that a reinstall of the client on the computer could potentially cause the server to come to a bit of a halt, if my conclusion is correct.

    Has anyone else seen this issue, or have any solutions? I'm pondering if we could up our VM to 2vCPUs to decrease the severity of the issue also..
  • Monday, August 17, 2009 1:18 PMTorsten [MVP]MVPUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Has anyone else seen this issue, or have any solutions?
    Any chance that it's SQL 2008 and it's the very first hardware inventory that hits the database?
  • Monday, August 17, 2009 1:45 PMCody DeHaan Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    It is SQL2008. It's potentially the first one (or was the first one, and it's updating the inventory for that first entry).

    Is this a known bug?
  • Monday, August 17, 2009 1:53 PMTorsten [MVP]MVPUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    John Marcum has already experienced this. I've pinged him offline ...
  • Tuesday, November 03, 2009 8:02 PMAdam Bertram Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Can you tell me what John Marcum has said?  I am seeing this exact same issue with the same scenario being SQL08 and a brand new install.  I'm trying to install SCCM SP2 but it won't let me because it's currently pegged at 100% CPU utilization.
  • Monday, November 16, 2009 4:45 PMAdam Bertram Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Proposed Answer
    I eventually applied SP2 which resolved this problem.
    • Proposed As Answer byAdam Bertram Monday, November 16, 2009 4:45 PM
    •