hi , i have an alpha server with memory usage reported as high as over 90% during the daytime, how can i know which is the culprit using up so much precious memory. Any free monitoring tools ?

Well , why is that bad ? If the page-fault rate is permanently high, then there is a problem to be solved ! How much is used by processes at a glance is reported by SHOW SYS (the right most column under the "pages" heading). And usually a MONITOR SYS command shows paging rates and the top page-faulting process. MONITOR PAGE gives all fault-rates, The important numbers are those for Read/Write I/O rate. Finally, when a certain process is identified as heavy faulter, do a SHOW PROCESS/ALL/ID=<process_id> , and see the peak virtual size and other memory related items. If processes are heavy faulting, consider to adjust it's memory quotas ( WSQUOTA and WSEXTENT in AUTHORIZE). And in addition, reading the VMS system managers manual(s) is always a good thing.

I forgot : MONITOR PROCESS/TOPFAULT This shows and identifies the most page-faulting process name/ID.

footsoldier, It is also possible that this is an intended behavior. 90% is indeed a large number, but with today's memory sizes it is not unusual for systems dedicated to certain applications (e.g., large databases) to have very large dedicated memory caches. In addition to the MONITOR commands that were mentioned by Joe Huber, you should also do a SHOW MEMORY/FULL command to display actually what is being used for what purpose. While it is worth investigating, 90% memory usage is not, in an of itself, a bad thing. It can be a bad thing or an ok thing, depending on the context. It is however, at least a potential limit on growth and should be understood. A thorough read of the documentation relating to performance tuning is also certainly appropriate. As a consultant, I have assisted clients with such questions for many years. The one constant is the variations that I see in client configurations. I have seen some situations where what is reported in your post is normal, appropriate, and intended. I have seen other situations where it is caused by a serious error. I have seen still other situations where it is intentional, but is not the most efficient use of resources to achieve the desired effect. The best advice that I can give is: Investigate with care. If fresh thoughts are desired as to the configuration and it use, retain outside expertise with experience in these matters (disclaimer: My firm does provide consulting services in these areas).

hi all, thank your for your kind advice, really appreciate. How do i make sense of the monitor process/topfault numbers ? it shows a scale of 0 to 20, and constantly jumping nos. next to it. The one with the highest no. is the top page fault?

First, You can start MONITOR without arguments in interactive mode. There is an online help inside. To make the top line less quickly changing, do e.g. a SET PROCESS /INTERVALL=10 This way You can catch the process-ID one-by-one. And please read the monitor documention, at least HELP MONITOR. It shows You also how to place monitor data output in a file for a specified time period (see the /DISPLAY and /ENDING qualifier).

footsoldier, With all due respect to Joe, I am not sure from the posting that the page fault rates are the first place to look. Please remember that some page faulting is inevitable, and not a problem. Spikes in page faulting are also normal. Similarly, sustained large amounts of page faulting are not abnormal with certain workloads. Additionally, the initial posting said that "90% of memory was in use", not that there was an excessive amount of page faulting. My general recommendation, admittedly made without details of the system workload, would be to first identify what the memory is being used for, not the page fault rate. I would also recommend considering installing the T4 package available free from the OpenVMS www site at http://www.hp.com/go/OpenVMS (then search fro "T4"). Presently, the link is: http://h71000.www7.hp.com/OpenVMS/p... T4 will allow the collection and storing of a data collection that can then be repeatedly analyzed in detail. I respect Joe's opinion, but I am not sure why we are presuming that the page fault rate is high, rather than say a pre-allocated database cache or other structure. - Bob Gezelter, http://www.rlgsc.com