G
George Potemkin
Guest
Buffer locks are "terra incognita" in Progress. That is why I think it would be a good thing to share our findings, assumptions and thoughts about how Progress uses the buffer locks. My assumptions in the previous post about how many buffers can be locked by a session at once turned to be wrong. Tested using the atm db with each table and each index resided in their own areas and running 150 sessions. My dbmon script was collecting the "Status: Buffer Locks" and "Status: Buffer Lock Queue" menus in promon. The average number of buffer locks per snapshot reported by "Status: Buffer Locks" was 161. The maximum 266. Minimum is 10. In other words, sometime almost all of 150 sessions were creating two buffer locks at the same time. And always it was one data block ("D") in disk I/O state (reported as "R" by "Status: Buffer Locks" and as "TIO" by "Status: Buffer Lock Queue") and the second one was an index block with SHARE lock. Data block always belongs to the "account" table. Index blocks sometimes belongs to the index of "account" table but sometimes (surprise!) to the index of "teller" table. 65% - index of "account" , 35% - index of "teller". It can't be explained by inconsistencies of the data that are rapidly changing. Dbmon collects data from both menus and called them sequentially /almost/ at the same time. Both menus shown that the same dbkeys were locked by the same users (when "Buffer Lock Queue" menu reports the real number instead of "-1"). In other words, promon is fast enough to report the more or less consistent snapshots of the buffer locks. By the way, the seqprobe test (an analogue of readprobe test) with CURRENT-VALUE() function is the best way to estimate how fast is promon's menus compared the buffer locks. The results, of course, depend from the -n and -B. The second note: we should not trust to the value in the "T" column (block type) when a buffer lock is in disk I/O state ("R" or "TIO"). Progress does not yet know the type of block it's reading from disk into buffer pool. Promon reads a block type from buffer header left by block that previously used the same buffer and which will be now evicted by new block. In our tests the types of blocks were identified by the area numbers. I /assume/ it's a reliable data.
Continue reading...
Continue reading...