.RM72 .LM5 .CENTER 72;Workshop on System Tuning, Performance Measurement .center 72;and .center 72;Performance Optimization of an RSX11M System .Center 72;May 20,1981 .CENTER 72;by .CENTER 72;James G. Downward .center 72;KMS Fusion, Inc. .center 72;Ann Arbor, Mich. 48106 .page .lit Goals For This Session o Techniques for making a system system perform better o Performance measurement as a tool for: a) Tuning a system. b) Understanding system behavior. c) Making decisions on system growth. .end literal .page .lit Speakers and Topics John Bennet DEC Problems in studying a live system DEC Capacity Planning Jim Downward KMS Fusion Performance measurement and Capacity Planning Thrashing and RSX11M Bulk core Disk Emulators Jeff Schriechime (DEC -DECnet group) Improving DECNET performance Steve Rusich DEC - RSX11M group BIG Buffering and how to get it. Workfiles and task increments. Mark Weston A user's experience with a system monitoring package. .end literal .page .lit Performance Measurement and Capacity Planing o Do before performance/capacity a serious problem. o Is system's performance and capacity adequate for its lifetime? o When (if ever) will it be inadequate? o Performance optimization? o Schedule system use? o Purchase new peripherials? o Purchase larger System? .end literal .page .lit Lifetime of a PDP-11 System o Select system based on fuzzy understanding of need. o Buy system. o Discover system is inadequate . o Add more capacity to system. o Problem solved. New applications and uses evolve. o Increased system usage and resource demand makes system again inadequate. o Procure still more capacity. o .. .. .. .. .. o .. .. .. .. .. o Decide a larger system is needed. o Don't know what system is needed. .end literal .page .literal Performance Measurement o Specifying performance is hard. a) Different hardware configurations b) Different end uses o Must develop transportable performance benchmarks. (RSX11M has none at present) o To specify performance/capacity must i) Quantify what the system does. ii) Approximate entire system use as collection of unit workloads. o Develop a simulated load to approximate the unit workload of the system. o Measure the throughput of the system as a function of unit workloads o Use measurements to explain present or predict future system behavior. .end literal .page .lit Plan for Future Requirements WHY: a) As system matures, uses expand. b) A large systems is a sizeable capital investment. c) Performance optimization: a stop gap measure. d) Long delays from order to delivery. e) Mistakes are very costly. PROBLEMS: o Lack of performance measurement tools. o Lack of performance comparisons between systems. o Decisions often based on a) guesswork b) hardware availability c) 'in vogue' processors, or tips. .end literal .page .lit Performance Measurement and Accounting Tools o Sources: a) Commercial vendors b) Accounting Working Group Documentation in campground c) DEC ??? o Accounting Working Group Still needs: 1) Report programs. 2) Task accounting for all tasks 3) Extract system use profile. 4) Multi-terminal virtual terminal support 5) Standard, tailorable, synthetic workloads for use as benchmarks. .end literal .page .lit Thrashing o RSX11M is prone to thrash if Demand for resources > available supply. Symptoms o One additional task degrades throughput drastically o Users call and say "system has gone out to lunch" o 9600 baud terminals behave like 10 baud terminals. o Large _# SHF... runs/hour. .end literal .page .literal Causes of Thrashing in an RSX11M System o Lack of memory o Memory allocation failures LDR checkpoints tasks in/out of core. Disk I/O uses large fraction of available time. o If swap time ~ Round Robin interval task will not execute for long. o SHF... Starts shuffleing and making checkpoint requests. o Excessive disk I/O activity. Long inter-track head seek times throttles throughput for all tasks. o Problem tasks SHF... Video editors RMDEMO .end literal .page .literal Solutions: Inadequate memory o Add more memory o Add cache memory so tasks exit sooner o Lengthen Round Robin and Swap intervals o Remove SHF... o Build tasks with FCS resident library. o Lengthen the Round Robin and Executive swap interval o Use a dedicated disk for the checkpoint file. o Run interactive tasks at a higher priority than CPU bound tasks. o Faster disk for checkpoint file o Disk Emulator for checkpoint file .end literal .page .literal Solutions: Excessive Disk Activity o Add additional drive, controller and ACP o Use Big-Buffering to cut down on disk I/O o Overlays? o Use driver which supports overlapped disk seeks. o Modify executive to insert I/O packets so disk seeks will be in assending order. .end literal .page .lit Problem Tasks: SHF... * Often a prime cause of unnecessary checkpointing/thrashing. * Can aggravate memory allocation failure problems. * If GEN large (PDP-11/44,11/70), repeated partition scans at system state will almost stop system. Solutions o Remove SHF... o Lengthen Executive Swap and Round Robin intervals o Limit _# times SHF... can run each swap interval (10-15% improvement on thrashing system) o Count SHF... runs and use as measure of when system memory is too crowded. Schedule system work. .end literal .page .lit Problem Tasks: Video Editors * Improve programing productivity, but .... * Video editors are large and sometimes ineficient. * Large size -> swapping if many editors in use 1) VTECO: Large, very inefficient. Degrades system performance 2) KED: More efficient, very easy to use. Bug causes it to thrash more than other video editors. 3) ED2 (EDT V2): Huge (22-32K !!), efficient, lots of bugs! .end literal .page .literal Solid State Disk Emulators o If can't stop disk thrashing, decrease disk I/O time o Solid state devices (core, semiconductor) emulate fixed head disks. Zero rotational latency times. Zero inter track seek times. Almost memory to memory transfer times. o Large (32K) tasks will swap in/out of system in small fractions of time to swap to a disk. o Dramatically improves performance of a thrashing system. o Small memory system performs as if it had substantially more main memory. o Taskbuild times can be significantly improved (30-40%) by placing system libraries on disk emulator. .end literal