Kaseya Community

Monitoring Counters Background

  • It would be nice to better understand the implications of these monitor items.

    For instance SQLServer. Wait Time

    8:43:41 pm 24-Jul-06

    Monitoring generated Counter ALARM at 8:43:41 pm 24-Jul-06 on folgers.clarin

    Monitor Set: SQL Server
    Type: Counter
    Log Object: SQLServer: Wait Time (ms)
    Alarm Time: 8:43:41 pm 24-Jul-06
    Log Value: 65073
    Alarm Operator: Over
    Alarm Threshold: 50
    Alarm Duration: 1 Minute(s)

    Given that the threshold is 50 and this server logged 65073, it would be very helpful to know what the counters are, why the thresholds are set where they are and what the counters are trying to measure or indicate. Otherwise, it's just a bunch of numbers. (yes we can google search these, but since these monitor sets we setup by someone, they must have some logic behind it)



    Legacy Forum Name: Monitoring Counters Background,
    Legacy Posted By Username: rvines
  • Sorry it seems that my notes in the description field were not exported. All these sets are supposed to have Description notes and I am not sure what happened... This was to help diagnose what should be done: So I re-googled it for you:

    If your users are complaining that they have to wait for their transactions to complete, you may want to find out if object locking on the server is contributing to this problem. To do this, use the SQL Server Locks Object: Average Wait Time (ms). You can use this counter to measure the average wait time of a variety of locks, including: database, extent, Key, Page, RID, and table.

    As the DBA, you have to decide what an acceptable average wait time is. One way to do this is to watch this counter over time for each of the lock types, finding average values for each type of lock. Then use these average values as a point of reference. For example, if the average wait time in milliseconds of RID (row) locks is 500, then you might consider any value over 500 as potentially a problem, especially if the value is a lot higher than 500, and extends over long periods of time.

    If you can identify one or more types of locks causing transaction delays, then you will want to investigate further to see if you can identify what specific transactions are causing the locking. The Profiler is the best tool for this detailed analysis of locking issues. [6.5, 7.0, 2000] Updated 6-12-2006

    Legacy Forum Name: Monitor/Event Sets/SNMP Sets,
    Legacy Posted By Username: sourceminer