From: SMTP%"krj@praxa.com.au" 27-JAN-1995 09:11:49.17 To: EVERHART CC: Subj: Re: SLOW SYSTEM: LACK OF RAM OR LACK OF STORAGE? From: krj@praxa.com.au X-Newsgroups: comp.os.vms Subject: Re: SLOW SYSTEM: LACK OF RAM OR LACK OF STORAGE? Message-ID: <1995Jan27.111144.134269@praxa.com.au> Date: 27 Jan 95 11:11:44 +1100 Organization: Praxa Ltd. Lines: 103 To: Info-VAX@Mvb.Saic.Com X-Gateway-Source-Info: USENET In article <1995Jan18.104508.602@rlgsc.com>, gezelter@rlgsc.com writes: > In article , ab915@cfn.cs.dal.ca (ED LAKE) writes: >> At work I use a DEC MicroVax 3400. Some days the system crawls along. >> Our system resource people inform me that its caused by too many people >> not purging previous file versions often enough and that it is the lack >> of disk storage which is bogging the system down. I had suggested that >> maybe not enough RAM may be the problem although this was dismissed. >> ...probably all of the above. Where to start? I'll assume Ed's responsible for this system, or wants to have a word with someone who is. The following ramble is derived from 12 years tuning a 50-vax farm X8-} Apologies for the length, but it's a frustrating subject and hard to know where to start. Just paying a few debts forward... ------------ Can you use $MONITOR and have access to $AUTHORIZE, and know how to determine and perhaps set system parameters, reboot a VAX? If so, the following may be of help -- if not, perhaps you can wave this in front of someone's nose and ask if they've covered these issues: Quick and easy way to get some assistance (above the level of Autogen, I presume you've tried that) is to get the version of VMS 6.? that has AMDS license bundled in, install that and run it. If there's something wrong, it will likely have an opinion about it. Check the SPD though -- don't know if it's much use without an x-windows terminal or workstation to get the right displays to you. (AMDS doesn't have to be on the same cluster). Second choice (may cost money) is whatever they're calling VPA these days -- (Polycentre Performance Solution or some such?) -- install that, read the release notes, collect data for a while and $advise performance report performance etc. Pretty valuable, as long as you ignore the advice about raising wsext for processes that use VMS Sort a lot. Failing to get all the above, check your mix -- 3400's a bit of a doorknob these days (no offence) and it may be a long and painful tuning job to get more than a few percent improvement -- the method is pretty well documented in the VMS Guide to Performance Management. It's well worth a read. Some rules of thumb that may not be in the book: o If you're using RDB, boost user process quotas. Too much is probably close to half enough :-). Get a good DBA to look at RDB performance, you can save heaps if your database isn't very well adjusted. o If system disk is overloaded (greater than say, 38 IO/sec or with disk IO queues above 3), install/share popular images, $set file/global on popular data files such as sysuaf.dat, vmsmail_profile.data if much VMS mail & logins, rightslist.dat if you're heavy on ACL's. o Alternately, you can improve IO performance considerably by using free list caching (presuming you have any free list to spare) -- check release notes for VMS on how to enable this. o If you have free list to spare but users are still paging madly (excluding "demand zero" paging, which is usually from image activation) then you're nobbling them -- they're being disallowed from using the memory you've got. Raise user's WSEXT to a little less than system WSMAX (not an issue beyond VMS 6.1, I think, where WSEXT is hard-coded to WSMAX by VMS). o If certain images are used a lot, give users WSDEF of at least the size of the largest of these images plus enough headroom for an RMS buffer or two, to keep image activations from expending too much time expanding your working set list. o Don't let VMS page itself -- keep SYSMWCNT high enough that the system page fault rate is below 2. o If you have directories with hundreds of files in them, no hope -- got to get the numbers down, either by purging or re-design (use text libraries where possible, use RDB instead of RMS files, etc.). There are some severe overheads involved with RMS directories over a certain size. o When was the last time your disks were defragmented? Use backup/restore, DFO, or one of the third-party defragmenters such as Diskeeper, Raxco, or PerfectDisk. I used to use DFO (the Digital product) and Diskeeper with pretty satisfactory results. o The best results, after all the above, may be a system upgrade. A good used 3100/90 for example, should be at least 4 times as fast as your 3400. More memory can definitely improve file performance via free list caching or global buffering. Replace your 3400 or simply cluster it with another machine. Good SCSI disks are a 2GB shirt-pocket item nowadays, and they may be cheaper buy than the time you're spending trying to get your current system to work. Good luck -- but I suspect you have a bit of a struggle ahead of you. Cheers, --kj Kelley Johnston {I may hold opinions which may not Praxa's be. } krj@praxa.com.au {49% of all statistics are made up on the spot. } {"Can I get my VT420 to write Carolingian Minuscule?"}