Question 32b Progress Above the 4G line

[TomBascom]

In many cases, yes, the root cause of the latch contention would be wonderful to solve.

But it is usually some deeply embedded bone headed design decision within the application that the DBA has essentially no ability to address.

 

[TomBascom]

Cringer, I don't see anything about buffer hits suffering in that PPT...

The numbers in there say to me that there are benefits going from 10 to 100 but not from 100 to 1000.

However -- that was a benchmark (readprobe) not the real world. So your mileage may vary. But readprobe is designed to simulate rapid readers. And there an awful lot of those out in the wild.

Anyhow, my personal "sweet spot" is 100. I think that 10 is not nearly aggressive enough. If I want to go lower than 100 I'd try 50.

 

[TomBascom]

... I downloaded it but could not make it work. Threw an error which I tried to track down, but my frustration level at that point was fairly high.

Remind me -- what was the error?

 

[kdefilip]

I guess in my mind I conceptualize this as two lists. But I'm okay conceptualizing this as one long list with two distinct ends.
From Progress documentation, in the absence of -lruskips (the default of zero), they state that when a new block gets entered in the pool OR an existing block is accessed, it immediately moves to the top of the MRU. An internal algorithm is used to maintain the other end of the chain, the LRU. All blocks at the end of the LRU chain are candidates for removal/eviction/replacement. By setting the -lruskips to a positive integer, we are essentially messing with that algorithmic system.
So I'm not sure what we are trying to solve by this setting. In my case, no segment of the buffer ever seems to reach 100 skips. So are we trying to solve a buffer that is so small compared to workload that there is contention in latch acquisition. If that is the case, there is a larger problem than skips that should be addressed.
Additionally, since no block ever reaches the threshold of skips, every block in the pool is a candidate for removal, regardless of its access priority.
So I'm just not sure what we are attempting to solve here. Yes, latch contention, but isn't the cause of the latch contention the far greater problem?

In many cases, yes, the root cause of the latch contention would be wonderful to solve.

But it is usually some deeply embedded bone headed design decision within the application that the DBA has essentially no ability to address.

Ahaha, I agree re "bonehead". How's that saying go; when life hands you lemons, fire the DBA

 

[kdefilip]

Remind me -- what was the error?

Placed in directory d:\cladmin, started command prompt with admin privs, cd'd to d:\cladmin executed pt3inst.bat, received following error:

This version of PROGRESS does not allow compiles. (471
R-code file not located for ".\lib\install.p". (473)
Press space bar to continue.

After hitting space bar, next error was:
** Unable to run startup procedure .\lib\install.p. (492)

Next space bar dumps me back at cmd prompt.

 

[kdefilip]

Think about very active blocks.

Suppose that some block is being accessed now and again. Every 1,000 or so times that *any* block is accessed this block will be. So under the old "strict" LRU algorithim it would, at worst, move 1,000 places from the MRU end of the queue.

With -lruskips 100 it could get all the way to position 100,000 before being moved to the MRU end.

Now think about a block in a "rapid reader". One which is being pounded on really hard. 1 in 10 blocks accesses goes to this block. It bounces between first position and position [HASHTAG]#10[/HASHTAG] constantly. With -lruskips 100 it does not get moved to the MRU end nearly as often.

The impact of that is that contention for the LRU latch is greatly reduced.

At the MRU end of the chain it doesn't really matter -- there is no special advantage to being at the front of the line.

At the LRU end of the chain it also doesn't really matter. The LRU end is still ordered the way that we want it to be. It is all stuff that nobody has accessed for a long time.

The great thing is that contention for the LRU latch is 1/100th of what it was.

In many very active Progress databases the LRU latch is the next source of contention once your major IO issues are resolved. So this is a big win for people with well tuned active databases.

Okay, thanks. That makes a lot more sense with the qualifier "a big win for well tuned systems". In my case I "feel" like LRU was tuned in an attempt to address some larger issue which, of course, seems a bit like a fool's errand.

Now if I can ask one more regarding this issue; if the skip count on any block never reaches the value of -skip, what does that tell you?

 

[TheMadDBA]

Placed in directory d:\cladmin, started command prompt with admin privs, cd'd to d:\cladmin executed pt3inst.bat, received following error:

This version of PROGRESS does not allow compiles. (471
R-code file not located for ".\lib\install.p". (473)
Press space bar to continue.

After hitting space bar, next error was:
** Unable to run startup procedure .\lib\install.p. (492)

Next space bar dumps me back at cmd prompt.

That is going to be the lack of a development license hitting you again... Maybe Tom can be persuaded to release an XCODE version that you can compile using the -rx option.

 

[TomBascom]

if the skip count on any block never reaches the value of -skip, what does that tell you?

That those blocks aren't being accessed very often.

But I suspect that "never" is probably your problem. I think you can see the current value at a particular point in time -- knowing the current skip count doesn't tell you how many times it has reached the skip limit and then reset.

 

[kdefilip]

That those blocks aren't being accessed very often.
Ah, okay. So that's a circular count that resets each time value is hit. Thanks.
But I suspect that "never" is probably your problem. I think you can see the current value at a particular point in time -- knowing the current skip count doesn't tell you how many times it has reached the skip limit and then reset.