Is there a maximum value on HeapsLocked and/or HeapsRelocatable connection property?

I am looking at a connection to a 32-bit 11.0.1.2405 database that is "stuck", and shows the following connection properties...

HeapsLocked 4294967266 HeapsRelocatable 4294967276

Since the largest unsigned integer is 4294967295, those numbers look suspiciously like "hitting a limit".

More...

Here is a snapshot of a few related properties. Does this prove the connection-level values are bogus? Or is it still possible the connection-level values are valid, indicating some serious problem in the engine?

engine...

2010-09-25 03:45:00.092,87,'HeapsLocked','Number of relocatable heaps currently locked in cache','21'
2010-09-25 03:45:00.092,89,'HeapsRelocatable','Number of relocatable heaps','204'
2010-09-25 03:45:00.092,100,'LockedHeapPages','Heap pages locked in cache','2175'

connection...

2010-09-25 03:45:00.014,81,87,'HeapsLocked','Number of relocatable heaps currently locked in cache','4294967255'
2010-09-25 03:45:00.014,81,89,'HeapsRelocatable','Number of relocatable heaps','4294967275'

performance

asked 24 Sep '10, 14:51

Breck Carter
32.5k●541●726●1050
accept rate: 20%

edited 27 Sep '10, 18:32

Looks like I'm going to lose my bet with Nick Elson, where I claimed I could get an answer here first :)

(25 Sep '10, 07:00) Breck Carter

In addition to the BOUNTY, I am offering FREE BEER.

(26 Sep '10, 17:57) Breck Carter

I bet the bounty & beer will go to Waterloo, ON...

(27 Sep '10, 12:35) Volker Barth

As I learned from Bruce Hay, the HeapsLocked should be <= LockedHeapPages. And so they are at least related to the address space/4096 you have available. Having this in mind your numbers look to me more like a free twice, so probably some dereferencing has brought them into the negative range.

(27 Sep '10, 15:10) Martin

@Martin: FWIW LockedHeapPages is not available as a connection-level property. But... that's a moot point, since the engine-level HeapsLocked and HeapsRelocatable values are much smaller than the connection-level values, indicating the later are probably bogus (as Mohammed indicates).

(27 Sep '10, 18:43) Breck Carter

flat view

One Answer:

active answers oldest answers newest answers popular answers

In the past, server/database/connection properties were updated on a "best effort" basis in order to keep the maintenance overhead of those properties low. When we update a property, no memory locking/barriers are used in order to prevent contentions on those locations in memory and hence slow down execution. Two reasons can cause a property to show unrealistic values: concurrency issues or software bugs.

A software bug happens when we mistakenly forget to update (increment or decrement) a property at the correct point in the code.

A concurrency issue happens when one property is being updated simultaneously by two or more CPU cores. Because counters were kept up to date on "best effort" basis, it's more likely that this will happen on multi-core machines. The good news is that as of SA v11, we have eliminated this issue. Without adding any CPU overhead, counter can not show unrealistic values because of CPU concurrency issues. This is only true for Windows and Linux. Other UNIX platforms are still on "best effort" basis.

Since you are already using v11 software, the only reason this can happen is because of a software bug in which we have incremented/decremented a property in one spot in the code, but forgot to do the opposite in a different spot. I will try to track this down but it would be more helpful if you can provide me with a repro.

permanent link

answered 27 Sep '10, 15:19

Mohammed Abo...
971●7●8
accept rate: 37%

Comment Text Removed

Are you saying this can ONLY be a case of bogus property values? See additional information in the question. In this case, the connection is "stuck"... not proceeding at all... no blocks, no activity, other connections work fine. FYI the problem is being investigated as open case #11629690, so that's where the reproducible is.

(27 Sep '10, 18:35) Breck Carter

Yes, it looks like bogus connection property values. For the HeapsLocks and HeapsRelocatable properties, the server values should be equal to the sum of the corresponding properties of all connections. In the example above, the server values are more realistic. For the connection values, something must have gone wrong there.

(29 Sep '10, 01:17) Mohammed Abo...

Another thing I wanted to add, if you sampling the properties at a high rate, you might get some bogus values for brief moments, but that should be corrected as subsequent samples are collected. The reason behind this is because the values are stored in a per-core memory region and when you request a specific property value, we go an sum up the values across all cores. Since accumulating the values across all cores cannot be atomic, you might get some values that don't add up.

(29 Sep '10, 01:29) Mohammed Abo...

flat view

Your answer

toggle preview

community wiki:

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

*italic* or _italic_
**bold** or __bold__
link:[text](http://url.com/ "title")
image?![alt text](/path/img.jpg "title")
numbered list: 1. Foo 2. Bar
to add a line break simply add two spaces to where you would like the new line to be.
basic HTML tags are also supported

learn more about Markdown

Question tags:

performance ×275

question asked: 24 Sep '10, 14:51

question was seen: 2,062 times

last updated: 27 Sep '10, 18:32

SAP SQL Anywhere

Is there a maximum value on HeapsLocked and/or HeapsRelocatable connection property?

Follow this question

Related questions