ANA/SYS show lock/sum

[Wim Van den Wyngaert]

Lockman Writes

The number of times that the Write Demon, in response to contention for a block held at exclusive write access and subsequently modified in cache, needed to physically
write a block to disk before releasing access to it.

Could it be that DSM uses the lock tree move mechanism for doing this (each lockman writes requires a lock tree move) ?

Wim

[Volker Halle]

Wim,

no. I don't think that the application is aware of lock remastering, it's happening 'behind the scenes'.

But each lockman action may just produce enough lock activity in that resource tree to cause it to be moved ?!

Volker.

[Wim Van den Wyngaert]

Volker,

Could be but it would be a miracle that each time the activity is on another node.

Wim

[Volker Halle]

Wim,

I don't know the DSM internals, but wouldn't the description given by Cass exactly lead to this kind of behaviour ?

If one node has the data block cached, the other node has to do something (with locking) to cause it to be written to disk, to then read it itself. Then this node would have the block in cache and the other node would have to do something to obtain the data block...

Something similar like this can be happening with RMS global buffers, if the you are writing a lot to the same file from multiple nodes.

Volker.

[Wim Van den Wyngaert]

"before releasing it". May be the tree simply moves because node A is wanting a lock and B releases the lock. Then a remaster "sole interest" is done.

Will do more monitoring ...

Wim

[Cass Witkowski]

DSM does not know about lock remastering. It does use OpenVMS locking for it's locking.

I would look at either setting the SYSGEN parameter PE1 to -1 to turn off lock remastering or locally mounting that DSM volume set.

You can use the ANASYS routines in DSM to show the cache contention.

[Wim Van den Wyngaert]

Cass,

Thanks for helping me on the right track.
The lock isn't visible because via my scripts because the lock tree only existed for a fraction of a second.

But if I set PE1, it could harm other stuff on the cluster so I will accept the tree move in case of contention. It is by average 0.74 but this average is caused by peaks.
Local mounting is not an option because of high availability.

Wim

[Cass Witkowski]

Wim

We have pe1 set to -1 and over 100 sites. It is also a dynamic parameter so you can change it and change it back.

Cass

[Wim Van den Wyngaert]

Cass,

There could be big lock trees that NEED to move because the activity is on the other node. If the lock tree is not moved, a lot of overhead could be created. I have seen an average enq rate of 8000. If the tree isn't moved this could lead to a serious slow down.

Just need more commands to analyze what is happening. Right now a log of every remaster would be great.

Wim

[Jan van den Ende]

Wim,


I have seen an average enq rate of 8000.


One of our applications has a number of application manager functionalities that run for 10 - 25 minutes, during which END/DEQ rate is between 100K - 250K.

Its database is a collection of multi(4-11) -keyed RMS files (totalling ca 3 G).
Still, we have no complaints about performance of other users, not even users of that same app.

fwiw,

Proost.

Have one on me.

jpe