In other words, the application design used a spin lock (a lock which if
unavailable uses an instruction loop consuming CP cycles until the lock
becomes available) in a manner that violates one or more of the most
basic rules for how spin locks should be used: (1)hold the lock for the
shortest time possible; (2)avoid holding spin locks in code segments
that can be interrupted and have the CP stolen; (3)use unique locks for
independent resources to minimize the total hold time for any one lock
and keep total lock hold time to a small percentage of a single CP.
All it takes is one interruptible application transaction holding a
application lock to lose the CP while holding the lock for all remaining
application transactions needing the same spin lock to loop. If this
and the other system workloads are enough to saturate all available CPs,
the looping and wasted cycles will continue until WLM finally decides
that the lock holder is more important and should be given another
chance to run. Murphy's Law pretty well guarantees that normal
application code (interruptible) using spin locks will eventually hit
this problem if the total lock usage time is high enough.
Even if the lock is only held by uninterruptible code, the design needs
to be such that the total time that the lock is held is only a small
percentage of the time available on one CP. As the demand for total
lock hold time increases toward and beyond 100% of one CP, all CP's will
approach 100% busy with remaining CP resources doing no useful work,
just waiting for access to the lock.
If an application needs to hold a resource for long periods, or with
interruptible code, or if the resource will be busy a significant
percent of the time, it should not be reserved using spin locks but some
other mechanism such as ENQ/DEQ or WAIT/POST which relinquishes the CP
if the resource is unavailable.
Bill Wilkie wrote:
Schmuel:
The only explanation I got was that the application developer was
inserting a transaction pointer into a large linked list and acquired
the lock before searching the list to find the insert point. It was a
custom application written for a very large customer. Someone else
mentioned that it seemed an improbable scenario. Be that as it may, it
happened.
Bill
From: "Shmuel Metz (Seymour J.)" <[EMAIL PROTECTED]>
Reply-To: IBM Mainframe Discussion List <[email protected]>
To: [email protected]
Subject: Re: Each CPU usage
Date: Tue, 28 Aug 2007 18:33:37 -0300
In <[EMAIL PROTECTED]>, on 08/26/2007
at 10:34 PM, Bill Wilkie <[EMAIL PROTECTED]> said:
>I would suggest that before you do the upgrade, check out SMF for
>excessive spin records
Why would an application, or CICS, acquire a spin lock in the first
place?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
...
--
Joel C. Ewing, Fort Smith, AR [EMAIL PROTECTED]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
