VAX/VMS PERFORMANCE TUNING FOR THE WORST-CASE SCENARIO 1987 Spring DECUS U.S. Symposium John F. Priebe Linda Schwambach Edison State College Computer Services 1973 Edison Drive Piqua, Ohio 45356 513-778-8600 513-778-9128 INTRODUCTION This session presents a case study of a small overworked VAX and what was done to delay disaster. If you feel that your site is a worst-case scenario, this session is for you. DISCLAIMER 1) Some of this goes against conventional wisdom. 2) Performance tuning is not an alternative to adequate hardware or efficient programs. SITUATION AT EDISON STATE COLLEGE 1) 2500 students enrolled, 100 taking computer classes. 2) Hardware configuration VAX 11/750 8 MB memory 2 RA81 disk drives (456 MB each) 1 RA60 disk drive (205 MB) 64 ports, DZ-11's and DMF-32's 3) Software configuration a) 6 computer languages taught. b) complete college administration software package. includes Admissions, Registration, Student Billing, Fiscal, Financial Aid, Payroll, Alumni. 4) Performance on typical days a) "slow" at best. b) the problem: no idle cpu time, no free memory, lots of page faults, occassionally too much disk i/o (often due to faulting). only resource not saturated are disks. three administrative users can saturate the system. running on the ragged edge - then add students. A DISCUSSION OF THRUPUT VS. RESPONSE TIME 1) Thruput - how many tasks complete in a given time. 2) Response time - how long one task takes to complete. 3) Want to maximize thruput while keeping reasonable response time for very interactive users. 4) Moderately interactive users may suffer. Some batch jobs may wait. 5) Best in the long run if insufficient resources. VMS MEMORY MANAGEMENT 1) Working Set parameters WSDEFAULT WSQUOTA WSEXTENT 2) Swapper trimming. 3) Swapping. 4) A little swapping is not necessarily a bad thing. STEPS TO FOLLOW TO TUNE YOUR VAX 1) Gather performance statistics. 2) Tune programs. 3) Tune processes. 4) Tune VMS. GATHER PERFORMANCE STATISTICS AND INFORMATION ABOUT YOUR SYSTEM 1) AUTOGEN See what it gives you first $ @SYS$UPDATE:AUTOGEN SAVPARAMS REBOOT 2) SYSGEN To list current parameters $ RUN SYS$SYSTEM:SYSGEN SYSGEN> SHOW/ALL 3) SHOW SYSTEM SHOW QUE/ALL/FULL SHOW MEMORY SHOW MEMORY/POOL/FULL 4) SYSTAT.COM and SYSTAT.FOR See VAX SIG Tape Spring 1987 [PRIEBE] 5) INSTALL $ INSTALL == $ INSTALL/COMMAND_MODE $ INSTALL INSTALL> LIST/FULL INSTALL> LIST/GLOBAL 6) AUTHORIZE Pay close attention to WS parameters UAF> SHOW ANYUSER GATHER PERFORMANCE STATISTICS AND INFORMATION ABOUT YOUR SYSTEM (CONT.) 7) MONITOR a) Run MONITOR every day from 8:00am to 5:00pm. $ SUBMIT SUBMON.COM which runs MONITOR.COM b) After collecting a days worth of data $ MONITOR/SUM=TT:/NODISPLAY/INP=MONSEP27.DAT SYS $ MONITOR/SUM=TT:/NODISPLAY/INP=MONSEP27.DAT PAGE c) After collecting several days or a months worth of data $ MONITOR/SUM=TT:/NODISPLAY/INP=MONSEP%%.DAT SYS This will give summarys and averages. 8) ACCOUNTING a) Enable accounting in SYSTARTUP.COM $ SET ACC/ENABLE=(INTERACTIVE,BATCH,DETACH,MESSAGE,LOGFAIL) b) Run ACCMONTH.COM at end of month. c) Examine reports. d) Draw graphs on plain-jane graph paper. TUNE PROGRAMS 1) Use more efficient languages. 2) Use more efficient algorithms. 3) 10-90 rule 10% of the code is responsible for 90% of the cpu time. the time spent tuning this portion will be a good investment. TUNE INDIVIDUAL PROCESSES 1) Priorities a) VMS does a reasonably good job of process scheduling. b) interactive: AUTHORIZE /PRIORITY=4. c) batches: Create batch queues to run at priority 3. if some batch jobs must be guaranteed of getting some cpu time VAX SIG Tape Spring 1987 [PRIEBE]BATPRI.COM VAX SIG Tape Spring 1986 [VAX86A.NU.QUEMON] d) do not waste cpu time adjusting priorities. 2) Batch queues a) train users how to submit batch jobs in the wee hours $ SUBMIT/AFTER="TOMORROW+03:00" CRUNCH.COM b) conceptually, batch jobs can wait almost forever VMS will schedule a batch job only when nothing else is able to execute. this keeps resources available for interactive users. c) create batch queues with low priority small number of concurrent jobs $ INIT/QUE/BATCH/START - /BASE_PRIORITY=3/JOB_LIMIT=2/WSQUO=1200/WSEXT=1800 - SYS$BATCH: d) the theory of "Get 'em in, get 'em out". 3) Print queues tell SYMBIONT_0001 to use more memory $ INIT/QUE/START/WSDEF=75/WSQUO=300/WSEXT=400 SYS$PRINT: TUNE INDIVIDUAL PROCESSES (CONT.) 4) Working set sizes a) theoretically, a process can run with only 2 pages. b) to run efficiently must have adequate physical memory. not so much as to be wasteful. c) ! because VMS will trim and/or swap processes, be liberal with WSQUO and generous with WSEXT. for databases, large statistical packages: WSDEF = 200 WSQUO = 800 to 1000 WSEXT = 1500 to 1800 for students: WSDEF = 200 WSQUO = 600 to 800 WSEXT = 1000 to 1200 TUNE INDIVIDUAL PROCESSES (CONT.) 4) Working set sizes (cont.) d) a bad example I saw... SYS$BATCH_STATS: WSQUO=300, WSEXT=300 needs WS of 1000 to 1500 pages. if you want to penalize a batch que, set priority to 1 rather than lowering WS. e) detached jobs $ RUN DETPGM/MAXIMUM_WORKING_SET=400/EXTENT=500 TUNE VMS (System-Wide Changes) 1) SYSGEN parameters and how to change them. a) modify SYS$SYSTEM:MODPARAMS.DAT b) invoke AUTOGEN $ @SYS$UPDATE:AUTOGEN GETDATA REBOOT 2) INSTALLed images (when to install, when not to). a) use /OPEN/HEADER for frequently opened images and data files. use /OPEN/SHARE for concurrent sharing of code. b) REMOVE programs which you do not use. c) ADD images which you do use. d) can ADD and REMOVE on demand. ex. PASCAL only on Saturdays. e) can share (and save) a lot of memory. f) put in SYSTARTUP.COM g) change GBLSECTIONS and GBLPAGES to match requirements before: GBLSECTIONS=150, GBLPAGES=10500 after: GBLSECTIONS=127, GBLPAGES=9100 TUNE VMS (System-Wide Changes) (CONT.) 3) Modify SYSGEN parameters to reflect real need. a) AUTOGEN often overestimates. ex: on VAX 11/750, MAXPROCESSCNT=90 (snicker, snicker) b) before: WSMAX = 4000 VIRTUALPAGECNT = 20480 MAXPROCESSCNT = 90 BALSETCNT = 57 SRPCOUNT = 917 IRPCOUNT = 641 LRPCOUNT = 23 c) after: WSMAX = 2000 VIRTUALPAGECNT = 12000 ! when not SDA (ANALYZE/CRASH) MAXPROCESSCNT = 45 BALSETCNT = 40 SRPCOUNT = 1247 ! my sys needed lots of SRP's, IRPCOUNT = 512 ! fewer of the others. LRPCOUNT = 14 d) memory savings. TUNE VMS (System-Wide Changes) (CONT.) 4) Encourage swapping. a) if memory becomes scarce, VMS trims to WSQUOTA, may trim more. b) may result in a process not having enough pages to run efficiently - thrashing. c) encouraging swapping (of idle processes) frees up large chunks of memory. d) set SWPOUTPGCNT to smallest WS for a program to run efficiently SWPOUTPGCNT = 480 ! default is 200 e) SWPRATE = 500 (5 seconds) prevents too much swapping. 5) Get rid of processes which make no progress. a) idea: give memory to someone else. b) DORMANTWAIT - swap if no significant event in 10 seconds. LONGWAIT - swap if user idle > 30 seconds. c) $ SET PROCESS/ID=pid/SUSPEND will cause process to be swapped out. 6) So, here's my MODPARAMS.DAT TUNE VMS (System-Wide Changes) (CONT.) 7) Misc. notes. a) changing some SYSGEN parameters may cause others to change. $ TYPE SYS$SYSTEM:SETPARAMS.DAT $ DIFF SYS$SYSTEM:SETPARAMS.DAT SYS$SYSTEM:SETPARAMS.DAT;-1 make sure something is not inadvertently changed for the worse. ( for example, if you decrease MAXPROCESSCNT, ACP_QUOCACHE will decrease also. but it may also decrease IRPCOUNT, and if you do lots of i/o, you may need to force this parameter higher in MODPARAMS.DAT. ) b) tuning is an iterative process. ( after making changes, watch your system and then make more changes. for example, you may have overestimated SRPCOUNT. Or, INSTALL may fail to add an image because too few global pages. ) 8) Increasing disk thruput. a) use BACKUP/IMAGE to reorganize disks. FOR FURTHER INFORMATION 1) System Management and Daily Operations. 2) System Generation Utility Ref. Manual. 3) Guide to VAX/VMS Performance Management. 4) DECUS Proceedings. 5) VAX SIG Tape, Spring 1987. QUESTIONS?