sys.dm_exec_sessions - High CPU

  • Hi

    I'm trying to work out which sessions are using the highest amount of CPU, this must be via script.

    I'm running:

    SELECT session_id, cpu_time, memory_usage FROM sys.dm_exec_sessions ORDER BY memory_usage desc

    could someone help me decipher what the 'memory_usage' parameter actually depicts?

    Has anyone else tried using this dynamic view to try and ascertain, quickly, which session is using the highest CPU?

  • Be careful with that. The CPU_time is the total time since the connection was established, not necessarily going to help much with identifying high CPU-using queries.

    Memory usage is probably the total memory grant the session has used, again since it was established.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • To add what Gail says, you need to run the query once saving the data into a temp table, wait for time, and then run again to compute the delta. Alternatively, run a job that polls the table every, say, 10 minutes. Be careful that a spid can log out and new connections and get the same spid!

    (And on the top of my head, I don't know what happens when a connection is reused in connection pooling.)

    [font="Times New Roman"]Erland Sommarskog, SQL Server MVP, www.sommarskog.se[/font]

  • .

  • What would you suggest is the simplest and most easy to read method of establishing which active session is using the highest amount of CPU? I want to stay away from using Performance Monitor and would ideally want the information extracting via a SELECT statement?

  • As Erland said, something that polls the table on a regular interval, stores the results somewhere and then you'd difference the latest and previous rows.

    What are you trying to do here?

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • Effectively, I need to be able to establish quickly which sessions are using a high amount of CPU.

    I'd want for example, a job to run every 5 minutes, which pulls the top 5 CPU consumers and writes them to a log file. If the client were to complain about performance problems, a quick check of the log file would the first port-of-call.

  • Use a sp_WhoIsActive with the @delta_interval option:

    http://sqlblog.com/blogs/adam_machanic/archive/2011/04/26/delta-force-a-month-of-activity-monitoring-part-26-of-30.aspx

    and you can also save the results in a table, but the @delta_interval option should be enough for you:

    http://sqlblog.com/blogs/adam_machanic/archive/2011/04/25/capturing-the-output-a-month-of-activity-monitoring-part-25-of-30.aspx

  • I don't think it's an official Microsoft SP?

    If that is the case, I can't use it 🙁

    Although it looks like exactly like what I need; just a snapshot of the current CPU usage/time listed by session ID!

  • wak_no1 (8/28/2013)


    Although it looks like exactly like what I need; just a snapshot of the current CPU usage/time listed by session ID!

    Then see Erland's suggestion from yesterday. That's how you'd achieve what you want.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • wak_no1 (8/28/2013)


    I don't think it's an official Microsoft SP?

    If that is the case, I can't use it

    Not Invented Here!

    Correct, sp_WhoIsActive is a very comprehensive work by SQL Server MVP Adam Machanic. And if you have a policy that you must write all queries and not use third-party software, free or paid for, the manager who invented that policy should be fired. You are wasting time by writing something that people has already implemented, and the risk is that you walk into the same traps as they did.

    [font="Times New Roman"]Erland Sommarskog, SQL Server MVP, www.sommarskog.se[/font]

Viewing 11 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic. Login to reply