Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!YALE.ARPA!LEICHTER-JERRY From: LEICHTER-JERRY@YALE.ARPA.UUCP Newsgroups: mod.computers.vax Subject: Re: Thanks and system hangs. Message-ID: <8703030012.AA24011@ucbvax.Berkeley.EDU> Date: Mon, 2-Mar-87 19:12:52 EST Article-I.D.: ucbvax.8703030012.AA24011 Posted: Mon Mar 2 19:12:52 1987 Date-Received: Tue, 3-Mar-87 22:46:03 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Distribution: world Organization: The ARPA Internet Lines: 70 Approved: info-vax@sri-kl.arpa We recently increased the number of logins allowed from 64 (default) to 120 on our 8650. Shortly there after the system would start to hang with about 70 or 80 users.... The last time the system started doing this I was able to do a 'SHOW MEM' from DCL and our swap file was more that 90% used, but the page file had plenty of free space. The best we could come up with is that our Swap files don't have enough space. We increased our secondary Swap file from 50,000 blocks to 100,000 blocks so far so good. Could it be something else? It's difficult to diagnose this at a distance, so I'll have to throw out a couple of ideas and hope they turn out to be useful: a) After increasing the number of users, did you run AUTOGEN? A lot of things depend on the number of users. b) You mention checking the and increasing the amount of swap file space. Did you also check for enough pagefile space this time? c) When you did the SHOW MEM, did you notice how full the primary pagefile looked? Unfortunately, not all page files are completely equal. Some things can go ONLY to the primary page file. In particular, page file sections will always live in the primary. RMS global buffers are page file sections, and ALL-IN-1 uses them.... 2. What is RWSWP (my guess is Resource Wait SWaPped) Well, more or less. The swap space allocated for a process grows and shrinks as the process's working set grows and shrinks. RWSWP means the process is trying to increase its working set, so needs more swapfile space, and is waiting for it to become available. The unavailability arises from lack of total swapfile space, or from internal fragmentation of the swapfile space. (This has nothing to do with disk or file fragmentation - it just means that the free space in the swapfile is split up by space allocated to other pro- cesses.) Again, make sure you have adequate pagefile space. VMS can page to the swapfile (or swap to the pagefile? - I forget which) if it has to to keep running, but the allocation strategies for the two kinds of files conflict, and the result will be a badly fragmented swapfile. (Actually, this probably has nothing to do with your problem, since you probably have to install the same file as both a pagefile and a swapfile.) 3. Where can I learn more about how to interpret what I get from SDA? As a start, get hold of the VMS Internals and Data Structures book, but Kenah and Bates. It's published by Digital Press. Unfortunately, it still corres- onds to V3 - a V4 version is due out "any time now". There are various courses on internals that are available through DEC, and others through DECUS. Much of the information available in those courses and their handouts is available nowhere else. 4. If this was the problem, how can I determine how much space per process should be allocated in the page and swap files. And why are so many processes being swapped out? If many processes are swapped out, the value of the SYSGEN BALSETCNT is too low. AUTOGEN does a fairly good job of determining reasonable numbers for this and related parameters. You might also look into VPA (VMS Performance Analyser?), a DEC product that watches your system running for a while, then recommends things you should do to improve performance. -- Jerry -------