|
HP OpenVMS Systemsask the wizard |
|
The Question is: Dear Wizard, Some processes on our system make page faults :-). They deal with RDB with Global Buffer option, so they should produce some quantity of Global Valid page faults. How can I distinguish between Global Valid faults (good and expected), page faults from secondary page cache (not so good, need to adjust WS params) and page faults from page file (bad) for certain process? I guess I can retrive third item from the PHD$L_PGFLTIO cell in the PHD. Is it correct? And another related question: These processes have unexpected big (close to WSMAX=PQL_MWSEXTENT) WS sizes. I suspect that the very Global Valid page faults force system to increment their WS sizes during AWSA, even though they dont't really need it. These processes have total page count in WS = 1/2 of WS size but more than WS quota, and it may be result of proactive memory reclamation (MMG$_CTLFLAGS = 3). So my question: Do Global Valid page faults affect AWSA process? I use OVMS/AXP 6.2 Thank you. Valentin Likoum The Answer is : There is no way to distinguish -- on a per-process basis -- how a particular soft page fault was resolved. The fault can be demand-zero (DZRO), global valid, from a transition list, or a collided page fault. Note too that page fault I/Os -- indeed accumulated in phd$l_pgfltio -- often read more than 1 page, in an effort to reduce subsequent additional pages faults. Now the more interesting question: why do you believe that global valid faults are "good" or "ok"? If a process incurs many of these, the AWSA logic can and should increase the working set. This has neglible memory costs as the same page is already used by another process, though it does require an element in the process working set list. So, yes, if Oracle Rdb uses substantial quantities of global pages for database caches, the OpenVMS Wizard would expect Oracle Rdb processes accessing these caches would use large(r) working sets. The size of entries in the working set -- the number of entries in the list -- is present in phd$l_wssize. Some/many of these entries may not be currently in use. For the total number of current pages, you would have to add pcb$l_ppgcnt and pcb$l_gpgcnt. If this value is much less than phd$l_wssize, then the process has been trimmed back.
|