| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1537.1 | | EPS::VANDENHEUVEL | Hein | Tue Apr 29 1997 19:55 | 34 |
|
> what's the implication of "high" rates in the above monitor dlock
> table entries ? ^^^^^^^^^^^^^
Nothing. It just suggests that the application is doing a lot of work.
> Converted ENQ Rate (Outgoing) is shooting up when a application
>is executing.
Over in the BASIC conference you just posted a query about an
application using an RMS indexed file having a heavy system
impact. I guess it is save to assume that this question is in
relation to the same problem? Why not tell folks a little more
about what you already know about the problem? What is the point
of letting voluntueering helpers go speculate about scenarios
where you can just provide the detail with the problem?!
> what's should be the interpretation ?
That it is doing a lot of work but not enough to move the lock tree over.
> and what advice you will give to lower this rate ?
Do less work. Ahhh, but you _want_ the system to do more work quicker
right? Well in that case you _want_ the system to get higher lock rates.
You may want to read up on lock-tree mastering and figure whether you
can concentrate access to a particular file to be from one node only.
hth,
Hein.
|
| 1537.3 | time to shuffle some hardware? | EPS::VANDENHEUVEL | Hein | Wed Apr 30 1997 05:23 | 56 |
| > One question is there are anything difference between monitor lock
> and monitor dlock ?
One activity is local to one node, the other (dlock) is distributed
and thus involved cluster communincations (CI traffic)
> nodes (3 nodes of VAX 7610 to be exact.)
Are they really 3 nodes with each 1 CPU?
They should perhaps consider getting rid of at least 1 box and
throw all memory and CPUs together in one node. Perhaps get one
more CPU to turn it into 2 times 7620. Some SMP power is so much
more pleasant for end user responsivness.
On a sinlge-cpu box, if a process goes hog a cpu as in your example,
then everyone else suffers immediatly as you noticed.
> suddenly jump, this application is only reading this file for
> locating list of records which satisfy the search criteria. The
[same anwer as from BASIC conference:]
That appears correct. As you read through the file RMS will repeat
the following approximate sequence for each record:
- [unlock previous if needed]
- lock bucket
- lock record
- [unlock current if ROP=NLK or FAC=GET]
- unlock bucket
There is NOTHING you can do about this. This WILL happen for each record.
The total number of lock transition is pre-defined by the number of
records in the file. The lock rate is simply a matter of how fast you
read through the file. Faster = better = more lock/second
They only way to have a real effect is to figure out a way not to read
the whole file. Use the key, add an extra key on a sub-field if needed.
> in the 3 nodes cluster. I try to investigate why this application
> is causing high lock rate. please advise.
As per above... the locking rate is not important it is just a
reflection off the work being done.
hth,
Hein.
|
| 1537.4 | lock rate investigation | HANDVC::STEVELIU | | Wed Apr 30 1997 05:35 | 31 |
| Hi, Hein,
yes, it is related to the same problem posted in VAX BASIC conf
note 1795. A new reply has been posted there.
One question is there are anything difference between monitor lock
and monitor dlock ?
Also I would like to understand this statement further :
"You may want to read up on lock-tree mastering and figure whether you
can concentrate access to a particular file to be from one node only."
why applications that access the same file should be localized to
one node ? what benefits can be obtained here ?
Rightnow the file is being placed on a shared disk which can be
accessed by different applications concurrently running on different
nodes (3 nodes of VAX 7610 to be exact.)
when this particular application is run, the lock rate in the system
suddenly jump, this application is only reading the file for
locating list of records which satisfy the search criteria. The
same file will be shared read/update by other applications running
in the 3 nodes cluster. I try to investigate why this application
is causing high lock rate in the system it runs.
will it be buffering problem ? can you tell from the output of
analyze/rms_file ?
steve
|
| 1537.4 | lock rate investigation | HANDVC::STEVELIU | | Wed Apr 30 1997 07:05 | 37 |
| Hi, Hein,
yes, it is related to the same problem posted in VAX BASIC conf
note 1795. A new reply has been posted there.
One question is there are anything difference between monitor lock
and monitor dlock ?
A high lock rate indicates that a certain resource is being hold up
for long. now does this resource refer to I/O resource only and is
this related to memory resource ? it is noted that when the lock
rate come up, disk I/O is seen to be jumping high too, and so
I am asking.
Also I would like to understand this statement further :
"You may want to read up on lock-tree mastering and figure whether you
can concentrate access to a particular file to be from one node only."
why applications that access the same file should be localized to
one node ? what benefits can be obtained here ?
Rightnow the file is being placed on a shared disk which can be
accessed by different applications concurrently running on different
nodes (3 nodes of VAX 7610 to be exact.)
when this particular application is run, the lock rate in the system
suddenly jump, this application is only reading the file for
locating list of records which satisfy the search criteria. The
same file will be shared read/update by other applications running
in the 3 nodes cluster. I try to investigate why this application
is causing high lock rate in the system it runs.
will it be buffering problem ? can you tell from the output of
analyze/rms_file ?
steve
|
| 1537.5 | | EPS::VANDENHEUVEL | Hein | Wed Apr 30 1997 13:29 | 15 |
| > it is noted that when the lock
> rate come up, disk I/O is seen to be jumping high too, and so
> I am asking.
Please put your thinking cap up for a moment... ready?...
As you read through a file, RMS will perform IOs to read buckets.
Each bucket will have a number of records. Let's say 50 on average.
So for every IO there will be 200 lock changes. If they read at
50 IO/sec, then there will be 10,000 Locks/sec. The more the better!
To read your whole 100K file with 5 block buckets you will need
approx 20,000 IOs and 4,000,000 lock. If you change the bucket
size to 25 there will be 4,000 IOs and still be 4,000,000 locks.
Hein.
|