Unusual _resrc usage - Forum - OpenEdge RDBMS - Progress Community
 Forum

Unusual _resrc usage

This question is answered

The following almost always results in zeros:

for each _resrc no-lock where _resrc-name = "shared memory":
  display _resrc.
end.

But I have recently found a few possibly interesting incidents at a customer site with non-zero values. Does anyone know what activities this resource is involved with?

--
Tom Bascom
tom@wss.com

Verified Answer
  • No, its all latch waits.

    The stat is only collected when latch statistics collection has been requested.

All Replies
  • Shared memory latch waits.

  • What sorts of events would require such a latch?

    Mere access to shared memory seems unlikely or wouldn't there always be tons and tons of these all of the time instead of it being a very rare thing?

    I'm wondering if it is being driven by something like "proutil increaseto"?  Or maybe memory in -Mxs being reallocated to -L when the lock table gets filled up? Or something like that?

    --
    Tom Bascom
    tom@wss.com

  • > Or maybe memory in -Mxs being reallocated to -L when the lock table gets filled up?

    Shared memory lock queue stays zero in such cases.

    I has checked my archive of customer's data: shared memory lock queue was always zero.

  • No, its all latch waits.

    The stat is only collected when latch statistics collection has been requested.

  • Aha!

    That makes sense.

    I will need to double check but I'm guessing that tech support's "gather" script enables latch statistics collection while it runs.

    --
    Tom Bascom
    tom@wss.com

  • I has enabled:
    2. Enable latch activity data collection
    and 'for each customer: end' results in:

    05/20/19        Activity: Resource Queues
    17:43:32        05/20/19 17:43 to 05/20/19 17:43 (17 sec)
    
    Queue                  - Requests -
                           Total
    Shared Memory           1215
    Record Lock               84
    DB Buf S Lock            177
    

    Total Locks in Activity: Latch Counts is 1051.

    The difference between Shared memory queue locks and Latch Counts is 164.

    Latch locks are counted in Shared memory queue locks. Plus something else.

  • Yes, the Tech Support promon gather script does indeed enable latch statistics collection.

  • George, type 1 object latches are counted twice, once for the governor, once for the object latch.

    Feature or bug?  I think we should add some additional statistics for the object latches then it would be clearer as to what is going on.

    In general LKP, LHT* behave as type 1 object latches but not always.  There are times for locking an entire chain where the object latch is not obtained, just the governor.

    With this in mind, the counts are more what you would expect given the sum of the latches compared with the "Shared Memory" Resource Queue report.

  • Thanks, Richard!

    > Yes, the Tech Support promon gather script does indeed enable latch statistics collection.

    Does it mean a kind of an official support for these options? Can we use them safely in production environment apart of possible performance degradation?

    2. Enable latch activity data collection

    3. Enable latch timing data collection

    Latch timing data collection does not seem to be implemented on some platforms. Where can we use this option?

  • It is not officially supported since the mechanisms have never been properly QA'ed.

    I would not expect it to crash or anything - that would be considered a bug.  But there is the possibility that the numbers reported are not accurate.  

    I don't see any platform where the latch timing is enabled anymore.  Is this something that would be useful for you if re-implemented?

  • > I would not expect it to crash or anything - that would be considered a bug.

    It's what I meant as "supported": the issues can be reported to PSTS.

    > I don't see any platform where the latch timing is enabled anymore.  Is this something that would be useful for you if re-implemented?

    I did not played with the versions where latch timing data collection was implemented. I can't say if it can be useful.

    I asked about this option just because the gather.sh script says:

    # Last modified 12/10/2013

    echo 2 >>gatherin.txt               #Enable latch activity collection

    echo 3 >>gatherin.txt               #Enable latch timing collection

    knowledgebase.progress.com/.../000010526

  • > On May 22, 2019, at 12:28 PM, George Potemkin wrote:

    >

    > I don't see any platform where the latch timing is enabled anymore

    It could be re-implemented now that there is decent low-overhead high-resolution timers on all the current processor architectures.

    An old implementation used gettimeofday() on most machines and a memory-mapped microsecond timer on Sequent machines. The cost to read the timer was one memory access. Back then, it was the 0only low cost timer available.

  • Yep, but I will not spend time on it if no one finds it useful.

    It has been missing form the product for a very long time and this is the first I've heard it mentioned and got no answer on if or why it would be useful.

  • agree.

  • Fact: duration at least of MTX latch locks may significantly vary depending from the external factors like a failure of disk in RAID or long queues of processes on OS level. "Significantly" = by millions (mayby billions) times. Number of latch locks/naps will be low during such extreme cases. I don't know if there are the situations where the duration of latch locks are only moderately increasing above normal - let's say, by tens/hundreds times. IMHO, the only way to see such situations is a latch timing.

    I would enable latch timing collection in the tests without competions for resources in shared memory - with only one session running. Just to estimate a percent of time the session locks resources compared to the total execution time. It will give an estimation how many processes can be run simulatiosly before the competion will become a bottleneck.