SQL Server 2008 R2 Activity Monitor

  • Have other people experience how slow the activity monitor is to populate. At times it is so slow I give up at use SP_who2 but would rather use the activity monitor. Have other got fustraded with the slowness? Just wondering if it is just me or that the way it is now.

    Thanks

  • It works fine for me and Loads in a fraction of seconds.

    Regards

    Regards
    Hema.,

  • Is that the same when u try to expand databasess in SSMS??

  • No everything else in SSMS works fine. But when I click on the activity monitor it just takes forever for the details to come back. It is slow at times with one instance with 1 or two user databses as it is wit a instance with 15 user databases. The data is just slow getting back to me.

  • Yes! It has been this way since we installed. It refreshes quickly enough; it's just the initial data load that's slow. We run a cluster and I was wondering whether that was a factor.

  • Hi

    Afaik I know the MGMT studio is sluggish on x64 as it's 32 bit.

    This might have the same issue for your machine.

    Also if you are on the server it will use shared memory.

    Try see if there is a difference from a remote machine which will most likely use tcip.

    Cheers

    Jannie

  • Jannie-186227 (7/20/2011)


    Hi

    Afaik I know the MGMT studio is sluggish on x64 as it's 32 bit.

    This might have the same issue for your machine.

    That's a good lead. I am curious about these details. Do you have an article that references these issues, or maybe how to mitigate them?

    Also if you are on the server it will use shared memory.

    I am able to force the use of TCP/IP on my local server by providing the IP address or the specific Port number when connecting.

    IP_ADDRESS\INSTANCE_NAME = TCP

    IP_ADDRESS,PORT_NUMBER = TCP

    .\INSTANCE_NAME = Shared Memory

    .,PORT_NUMBER = TCP

    SERVER_NAME\INSTANCE_NAME = Shared Memory

    SERVER_NAME,PORT_NUMBER = TCP

    (local)\INSTANCE = Shared Memory

    (local),PORT_NUMBER = TCP

    Note: my client protocol priority was not changed from the default order -> Shared Memory first, TCP/IP second, Named Pipes third

    You can check your transport with this query after connecting:

    SELECT net_transport,

    endpoint_id,

    connect_time,

    client_net_address

    FROM sys.dm_exec_connections

    WHERE session_id = @@spid ;

    There are no special teachers of virtue, because virtue is taught by the whole community.
    --Plato

  • I can't say I have noticed any sluggish behaviour; SSMS behaves just fine for the most part, it's just the initial load of data by the activity monitor that takes "forever" -- 3 min 45 sec just now.

    Unfortunately, I haven't noticed any difference between my current 64-bit and previous 32-bit desktop. Nor does it seem to make any difference whether I am logged into the server or my desktop. Come to think of it, as I always remote desktop into the server, that last may not be true.

    Richard

  • It loads quite slow for me as well, kind of frustrating I agree.

  • Yep the activity monitor load is slow as all get out if you server is the slightest busy. It does not matter if it is a cluster or stand alone, it is slow.

    If you having a block or other issue going on and want to see an overall real fast, better use something like sp_who2 for faster response.

  • Well, sod it! I hope MS does something about that soon.

    Thanks for the info, all the same

    Richard

  • When I open it up on the Physical server it opens quicker. I wonder if it has to do more behind the scenes due to the CPU, Waits, IO, other stuff so it might take longer.

  • I've used it on physical, virutal and clusters. It does not matter what it is on if SQL server is busy handeling request, it's slow. People that say it's fast, does not have 100 + sessions connected to the server working. Or the open their local dev server instance and says it opens fast.

    It does connect fast if the server is not doing work.

Viewing 13 posts - 1 through 12 (of 12 total)

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