Regions and collisions

[former_member192710]

Folks;

in preparation for an internal (non-SAP) training related to MaxDB performance analysis and tuning, I am taking a first look at the relevant tools to get an impression of what's possible and what not. Dealing with x_cons I stumbled across the following thing:

bflow@pvdbsrv:~$ x_cons BFLOWDB show regions

SERVERDB: BFLOWDB

Index  Region    Owner    Get-Cnt    Tas-Cnt      Coll.    Waits Excl   Coll % 
    1  PAGER                19393          1      75226      585    0 387.90 %
    2  CONFIG                   0          0          0        0    0   0.00 %
   ...
   27  SERVER              131145          0          3        0    0   0.00 %
   28  SRVTASK              12346          8      12906      122    0 104.54 %
   ...

Browsing this pages, I found (1) and (2) to be of interest yet not completely resolving my questions, especially related to the, well, oustandingly high collision rate related to the PAGER region. Should I be worried?

Thanks in advance and kindest regards,

Kristian

(1)

(2) http://wiki.sdn.sap.com/wiki/display/MaxDB/SAPMaxDBRegions

Edited by: Kristian Rink on Sep 10, 2009 9:17 AM

Edited by: Kristian Rink on Sep 10, 2009 9:18 AM

[lbreddemann]

> Browsing this pages, I found (1) and (2) to be of interest yet not completely resolving my questions, especially related to the, well, oustandingly high collision rate related to the PAGER region. Should I be worried?

Outstandingly high compared to what?

Let's be very clear about it: we're talking about locking mechanisms here.

Whenever there are two or more tasks trying to work on the same resource at the same time, you'll see collisions on the regions.

And since regions are check again and again by the task that wants to get the resource access, it might well be that it has to try this several times.

Thus you can reach >100% collision rate compared to the number of times the resource access was granted.

Just to give you (and the readers of this thread) a short warning: "high region collisions rates" is not the same as "bad performance" or "DB problems".

The DBanalyer does unfortunately report quite too many warnings, that are pretty often rated too seriously.

However, this tool is not focussed on reponse times of the database its components, but on heuristics and expectations of the development on certain counter statistics.

Nobody can tell you, wether 150% collision rate for any region is good, bad or doesn't matter at all.

That's because, we cannot kow what fraction of the systems response time goes into these collisions.

In general looking at these kind of numbers (also like cache hit rates, or times an index have been used) is not useful to figure out whether there is a performance issue or not and where to look for the reason.

My opinion on these numbers is, that they are made available, because it was easy to do that.

Plain and simple.

It's not about beeing able to analyze the performance very efficiently - it's just that certain numbers 'fall off' the implementation of data structures.

I know this does not help a lot know - but to calm your worry: the pager works asynchronously and independent from the user tasks. Therefore they don't need to wait for it, which means: no performance problem to you.

regards,

Lars

[former_member192710]

>

> > Browsing this pages, I found (1) and (2) to be of interest yet not completely resolving my questions, especially related to the, well, oustandingly high collision rate related to the PAGER region. Should I be worried?
> 
> Outstandingly high compared to what?

Compared with the screen shots posted in the PDF found somewhere around here where these collision rates altogether are < 1% it seems.

Seriously: My problem is that, at the moment, we're suffering from serious performance issues in parts of our system, and we are step-by-step looking at the various components to see whether they could be (at least partially) to be blamed for that. MaxDB is due for that next week, and I just stumbled across the number which "feels" large - in most situations in which I had to deal with collisions so far, "high" collision numbers usually were thought of as something bad. So I wanted to have a better understanding of what's going on here, which now I do have I guess. Thanks for pointing me there!

Kristian