Sybase Spinlocks Test

Spinlocks are lightweight synchronization primitives which are used to protect access to shared resources. The spinlocks can only be updated automically when the resource is accessed to perform a user task. The spinlock denies all other tasks access to the resource until the changes are made by the current user task as a result other user tasks are made to wait, this in turn causes spinlock contention. Although, the spinlocks are held for extremely brief durations, they can increase CPU resource utilization and reduce performance of the Sybase server with high transaction rates. Therefore, the spinlocks should be monitored to avoid such excess CPU utilization and performance lag of the Sybase server. The Sybase Spinlocks test helps administrators greatly in this exercise.

This test auto-discovers the named spinlocks and reports the percentage of spinlock contention on the resources, CPU cycle spinning activity, and grabs and waits of each spinlock.

Target of the test : A Sybase ASE server

Agent deploying the test : An internal agent

Outputs of the test : One set of results for each spinlock being monitored.

Configurable parameters for the test
Parameter Description

Test Period

How often should the test be executed.


Refers to the IP address of the Sybase server.


The port through which the server communicates. By default, it is 1433.


To enable the eG agent to connect to the Sybase server and collect the required metrics, specify the credential of the Sybase user who has the “mon_role”.


The password corresponding to the above user.

Confirm Password

Confirm the password by retyping it here.

Measurements made by the test
Measurement Description Measurement Unit Interpretation

Spinlock contention

Indicates the number of times an engine encountered this spinlock contention on the resource, and had to wait as a percentage of the total spinlock requests for that resource.


The value of this measure should not exceed 10%. For example, if the spinlock contention is more than 10% in the cache, consider using named caches or adding cache partitions. The number of cache partitions is always a power of 2 such that you can approximately reduce half of the spinlock contention when you increase the number of partitions each time.

The detailed diagnosis of this measure, if enabled, provides details such as SpinlockslotID, Ownerpid, Lastownerpid, Spid, login name, Status, etc.

Grabs rate

Indicates the number of grabs for this spinlock per second.



Spins rate

Indicates the number of CPU spins that are made per second to acquire this spinlock.


Ideally, the value of this measure should be low. A significance increase in the value indicates high CPU utilization, which results high performance lag.

Waits rate

Indicates the number of waits that are occured per second for this spinlock.


If the value of this measure is consistently high, identify which resource causing waits and fine tune the appropriate SQL queries.