G
George Potemkin
Guest
I has updated my LatchMon.p program that I used during the tests with the latches. Program requires Progress V11.5 or higher. It reads the _Latch VST 10 times per second (the default polling interval is 0.1 sec) and creates two reports for the specified number of the sampling intervals: LatchStat. .txt - statistics per latches. LatchHold. .txt - latch statistics per users (for the most active users only). LatchStat reports apart of the usual columns like "Locks" and "Naps" and some auxiliary "technical" fields contain two new columns: "Busy%" - percent of time the latch was busy. Note that neither high latch locks nor high latch naps (waits) indicate that latch is busy. The value in "Busy%" is calculated as the number of times when _Latch-Owner catches the current latch owner compared to the number of checks ("Polls") done per sampling interval. Average latch lock duration can be estimated as the ration of "Busy%" to "Locks" values. "Users" - the number of users that were caught during the checks as a last latch holder (_Latch-holder). Of course, both values exist only for regular (plain) latches. LatchHold reports the total number of latch locks ("Locks") plus "User%" column - how many time a particular user was caught as a last latch holder. "BgnTime" and "EndTime" is the first/last time the user was found as a holder of /any/ latch during the current sampling interval. "DbAccess", "*Read", "*Write" is the user's activity between BgnTime and EndTime. It will be a bad sign if LatchMon.p will create the third report: LatchLock. .txt The file will reports all cases when a latch was locked longer than a polling interval (e.g. 0.1 sec or longer). It's a million times longer than a normal latch lock duration (~ 100 nanoseconds) but it might happen especially with the MTX latch. The program can be downloaded there: ftp.progress-tech.ru/.../LatchMon.p
Continue reading...
Continue reading...