Kbase P23850: What is the -spin parameter?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
5/20/2011 |
|
Status: Verified
GOAL:
What is the -spin parameter?
GOAL:
How to use -spin?
GOAL:
How to calculate the Spin Lock value, -spin
GOAL:
How to set -spin
FACT(s) (Environment):
All Supported Operating Systems
Progress/OpenEdge Product Family
FIX:
On multi-processor systems, Progress uses a spin lock algorithm to control access to shared-memory structures and acquire the resource's latch. Spin locks ensure that only one process can use the structure at time, but that all processes can get access to these structures quickly when they have to. When a process needs access to a resource, it tests the lock and finds it to be set by another process. The process tries to access the resource or ?spin? a specific number or times before it temporally ?rests?. The temporary rest is termed "latch timeout" and the number of retries before resting is controlled by the -spin parameter.
Tuning -spin essentially means increasing its value until the number of latch timeouts no longer decreases. Increasing -spin will also cause an increase in cpu consumption, so when CPU consumption gets above 90% it should be decreased. Refer to Solution P92353, "How does CPU speed relate to values to set for -spin"
Spin Lock Retries (-spin)
The database startup parameter syntax is:
-spin <n>
where:
<n> is the number of times a process tries to acquire a latch before napping.
Use Spin Lock Retries (-spin) to set a value to use the spin lock mechanism or a system of semaphores and queues. If the value of n is greater than 0, a spin lock algorithm is used for shared-memory data structures as opposed to semaphores. Once -spin is activated, when a process has to lock a shared-memory structure, the process tries up to n times to acquire the latch for that structure. If it has not acquired the latch in n tries, then the process pauses, or naps. The length of the pause increases gradually if the process repeatedly fails to acquire a latch. After the allotted nap time, the process wakes up and tries to acquire the lock again. If it fails to acquire the lock, it will retry up to the number of tries specified by n.
If the value of n is 0, a system of semaphores and queues is used instead of spin locks. The spin lock algorithm is much more efficient than using only semaphores in a multiple processor environment with the Enterprise database license.
In some cases, if the value of n is 1, it might improve performance even on a single CPU core machine because Progress uses the spin lock mechanism. Do not set this parameter to a value larger than 1 if the machine has only one processor core.
On multi-processor/core machines (SMP), start with a value of 8,000 per CPU. If this causes too much CPU usage, reduce the value. If the server has many fast processors/cores, a value as high as 10,000 may be a more effective ballpark starting point.
The efficiency of -spin can be evaluated through the Progress Monitor (PROMON utility) R&D options. The -spin parameter controls a performance indicator called "resource waits". By setting the -spin value higher, resource waits are reduced. Note that when setting the -spin value higher ceases to reduce the resource waits, continuing to set it higher can effect CPU utilization adversely. To view the resource waits value:
- Access PROMON and enter R&D at the main menu.
- Choose option 3, Other Displays, then choose option 1, Performance Indicators, to view the resource waits. Resource waits is the last item reported in the listing.
The current value for -spin, if set at initial database startup, can be noted and adjusted while the database is running using:
promon R&D > 4. Administrative Functions > 4. Adjust Latch Options > 1. Spins before timeout
The -spin parameter, as with all performance utilities, is only available for use with the Enterprise database license.
In earlier versions (e.g. Progress 9.1D, 9.1E), resetting the value of -spin through the promon 1. Spins bef.ore timeout (detailed above) was not working correctly. So using the following ABL code as a workaround, allows the value to be checked and reset on-the-fly:
/* updatespin.p */
For each _Startup:
update _Startup-Spin.
end.
This behaviour is fixed in OpenEdge 10.1A onwards..