A simulation mo del for data base system performance evaluation

Transcription

1 A simulation mo del for data base system performance evaluation by FUMO NAKAMURA, KUZO YOSHDA and HDEFUM KONDO Hitachi Limited Yokohama, Japan NTRODUCTON Performance evaluation represents one of the most critical and also most complex aspects of the design of a data base system for operation in an on-line environment. l\1ost techniques for computer system evaluation (such as software and hardware monitoring) presume that the system or at least a skeletal version of it is operational. Such techniques are useful primarily for turning already developed systems. Simulation, on the other hand, although it is expensive, offers a way to evaluate a system with relative accuracy prior to its development. By varying design parameters, the system designer can hope to identify potential bottlenecks, avoid costly design mistakes, and eliminate some of the guess work of identifying the most suitable system solution. The subject of this paper is a large scale simulation model which was developed for data base system performance evaluation. The model, which is used for evaluation of design alternatives for application systems as well as system software (OS (Operating System) and DBMS (Data Base Management System)), employs event-driven simulation of the actual operations of hardware, host operating system, DBMS, and application programs. Great care was taken to model OS and DBMS functions, such as task scheduling, /O interrupt processing, communication processing, message scheduling, data base access processing, buffer management, and disk space management independent of any application characteristics. n order to evaluate an application data base system, description of hardware configuration and data base characteristics, as well as application program models, must be prepared. l\1odifications of the actual model are required only if alternative OS and/or DBMS architectures are being examined. Once the user has developed a model of his system, its behavior can be evaluated with relative ease, by simply modifying parameters such as message traffic, data base buffer set size, number of concurrent application program tasks, data base organization, and disk storage allocation. The remainder of this paper gives a presentation of the model, discusses some simulation results, and outlines approaches for further development. SMULATON MODEL The simulation model written by using a computer system simulation package has two major portions, definition part and procedure part. The definition part describes the system environment being simulated, while the procedure part represents the software system using an instruction set prepared by the simulator. The simulator executes instructions in the procedure part interpretively referencing information in the definition part. Our model consists of the following components. Definition Part (1) Hardware description (2) Application description Procedure Part (3) Operating system model (4) Data base management system (DBMS) model (5) Application program models For an application system, (1), (2) and (5) must be prepared to be input into the simulator. Figure 1 shows an overall view of the model. The following is obtained through simulator runs. Resource utilization (CPU, channels, disks, magnetic tapes, lines, etc.) Frequency of each software module usage Response time and throughput Number of data base l/os Queue statistics From the above information, the designer can estimate the capacity of his system, identify bottlenecks and critical factors, which enable him to decide improvement steps, and consider the trade-offs. Hardware description t includes configuration description and definition of the following hardware characteristics. CPU-instruction mix (CPU speed) Lines-transmission rate and delay 459

2 46 National Computer Conference, 1975 Terminal Queues, J l t Communicaf------t"-... tion Support Message Scheduler Scheduling Queue nput Message Queue Communication Processor Message Buffers Task Schedule Ready Queue Wait Output Queue Message Queue : L, Buffer Manager /O /O nterrupt Routines Application Programs Data Access t----- Service Disk Space Manager Access Methods (s?) L J. Figure -Overall view of simulation model Terminals-message generation rate and distribution Channels-data transfer rate and channel interference rate Disks-data transfer rate, cycle time, seek time characteristics and RPS (Rotational Position Sensing) lead and hold time Magnetic tapes-data transfer rate and start time A pplication description The most important information here is the data base definition characterized by data structures, storage structures and access methods. Figure 2, Table and Table show how we are dealing with data base definition in the model. (1) Data structures-the DBMS supports hierarchical data structures, composed of an aggregate of elements called segments. Each segment has one parent segment except a root segment and any number of child segments. tem 6 to the last in Table describe a data structure. (2) Storage structures-tem 2 and 5 in Table and item 2 to 7 in Table are concerned with a storage structure which, due to its nature, cannot be easily represented in a model; that is, there may be tens of thousands of records or millions of records and a model can never keep the exact position of each record except environmental information such as disk type, block length, and file allocation on secondary storage. The only information related to the above problem is the segment overflow ratio in Table and this information and some additional data base access calls will make up for the problem. (See DBMS model) (3) Access methods-the DB]\tS supports, as basic access methods, Sequential Access Method (SAM), ndexed Sequential Access Method (SAM) and Direct Access Method (DAM). Data Base Definition Tables File Definition Tables Figure 2-Table relationships in data base definition Operating system model Excluding comments, 4 simulator instructions were required to model the following operating system functions. (1) Task scheduler-a data base system in an on-line environment is executed in multi-programming and/or

3 A Simulation Model for Data Base System Performance Evaluation 461 (2) (3) No. TABLE -Data Base Definition Table Data Base Name CONTENTS 2 Disk Type to Store Data Base 3 Pointer for FDT 1 4 Pointer for FDT 2 5 Segment Overflow Ratio 6 Number of Segments in Data Base 7 Segment Name 8 Segment Length 9 Segment Level in Hierarchy 1 Parent Segment Name 11 Occurrence under Parent Segment Repeat 7 '" 11 until Last Segment multi-tasking modes, which requires a module for task management. This module attaches and detaches tasks to the DBMS and application programs, maintains ready and wait queues, and activates and inactivates tasks according to their priorities. Communication support-this component manages communication lines and terminals, controls polling, sends and receives messages and services message /O completion interrupts. A productive poll which follows message transmission occurs when a terminal generates a message. After message transmission has completed, the message is put into the input message queue. An output message in the output message queue, on the other hand, is sent to a terminal, which causes an output transmission completion interrupt that restarts polling. /O interrupt service routines-the model has /O interrupt routines according to /O device types which involve magnetic tapes (for log data), HTAC 8578 Disk Storage (cycle time 25 ms, average seek time 6 ms, capacity 29 MB) and HTAC 8589 Disk Storage (cycle time 16.7 ms, average seek time 3 ms, capacity 1 MB). Completion of read, write and seek gives control to these routines. DBMS model Two thousand three hundred statements are used to model this part which, consisting of the main controller, the communication processor and the data access processor, is the most important part in the model. (1) (2) (3) Main controller-this component manages the whole DBMS, which means that it gathers log information, controls the status of the data base system, schedules messages and communicates with and controls messages. t gives control to the communication processor when an input message arrives. After communication processor's service, it schedules the message according to the priority and activates an application program. A data access call from an application program makes it give control to the data access. Communication processor-t services input and output messages under communication support in the operating system and gets control when, (a) communication support completes message input and output, and (b) a message to send exists. t moves an input message from the input message queue to the scheduling queue and makes a copy on a disk at the same time. Transmission completion service of an output message causes it to issue a request to restart polling to communication support. When a message is in the output message queue, it issues a command to send out the message to communication support. Data access-t is activated by a data access call from an application program. ts major modules are service routines for data access calls, i.e., retrieve, insert, replace and delete, buffer and disk space management modules, and modules to support access methods (SAM, SAM, DAM). The model supports a set of primitive data access call functions including Get Random, Get Random Next, Get mmediate Next, Get Link, nsert Random, nsert mmediate Next, Replace and Delete. For example, Get Random selects a record randomly among all data base records given by data base definition, determines the physical address, and accesses it; Get Random Next calculates the distance, within a record, between the segment No. TABLE --,-File Definition Table Access Method CONTENTS 2 Start Address in Disk Number 3 Start Address in Cylinder Number 4 N umber of Blocks Allocated 5 Block Length 6 N umber of Blocks per Track 7 Logical Record Length

4 462 National Computer Conference, 1975 Access Methods Data Base /O Requests Buffer Management Module Buffer Set Reference chain Example: Process DA CTR=5 A Process DA 2 (instruction steps) GR, DB, SG1 (GR: Get Random) 1 GRN, DB1, SG2 (GN: Get mmediate Next) CTR=CTR-l f CTRO Go To A L/, \ \,, Buffer Address in Buffer Set Buffer Size Data Base Name br::ddress in Buffer Empty Flag Buffer Busy Flag Write dentifier Reference Chain nformation attached to buffer Figure 3-Buffer management position and buffer information to be obtained and the one accessed before based on the hierarchical structure of the data base and each segment's occurrence and gets it; Get mmediate Next brings the next segment immediately after the current segment; Get Link issues one random physical read to the specified data base. The LRU (Least Recently Used) method is used in the buffer management module which is one of the most important modules in the DBMS model. All data base /O requests are processed through this. module. Figure 3 illustrates the position of buffer management and information attached to each buffer for its manipulation of the buffer set. Buffers in the buffer set are chained by reference chain. At the time of data base access the buffer management module searches the buffer set at first by tracing this chain, and if the required data don't exist in the buffer set it tries to get buffer space to read the data from disk storage by tracing the chain backwards. The module also.controls concurrent data base access. A pplication program model User application programs are modeled in this part. The model mainly involves CPU steps spent in application programs, control of the process and data access calls with the following format: DA call function, data base name, segment name EXAMPLES OF SMULATON H ardware configuration-nsurance company Figure 4 shows all equipment components, some of which (the console typewriter, card readers, line printers and most magnetic tapes) are not necessary for simulation. The central processing unit (CPU) has a.1j,l second machine cycle time, a.9j,l second memory cycle time and 16K byte high speed buffer memory and supports four-way interleave. We decided on a CPU speed of 1.6J,L seconds per instruction which was gotten by the other project. There exists no channel interference as the /O processor processes all data /Os. Forty (4) disk storage devices are connected with 6 control units and 2 block multiplexor channels and have 3 millisecond average seek time, 16.7 millisecond cycle time, a data transfer rate of 8K bytes per second, and a 1 million byte capacity per spindle. The model also simulates RPS (Rotational Position Sensing) action. Only one or two magnetic tapes for logging are necessary to simulate the system because simultaneous background jobs are left out of consideration. The tapes have a data transfer rate of 24K bytes per second and 3 millisecond start time. There are 25 terminals connected with 3 lines with a speed of 12 bits per second. Message length is within a range of 3 to 8 bytes. Poisson arrival of messages is assumed. Data bases-nsurance company Eleven data bases, most of them constructed by SAM and DAM combinations, are contained in the system and have totally about 6 million records which occupy 32 disk packs. The data structures are not so complex, however, as their hierarchical levels are two or three. The largest data base is the car insurance data base which has 1.3 million records and requires 9 disk packs. SAM files have four kinds of indexes, super index, master index, cylinder index and block index, where super and master indexes are always in core and also cylinder indexes in some cases. All data bases have the same block size of 24 bytes which allows for five blocks per track.

5 A Simulation Model for Data Base System Performance Evaluation 463 * t includes 2 percent not in buffer ratio H87 CPU 1.6* Jls/inst. (MM 1.5 MB) H8589 Disk Storage Traffic: 1 Msg/hr 25 Terminals 3 Lines 12 bps Console MPX lop :: 14 decks 6 H8455 Magnetic Tape System (24 KB/ sec) Figure 4-Hardware configuration ( AV. Seek Time: 3 ms ) Cycle Time : 16.7 ms Data Transfer: 8 KB/sec. ----{j 8 Spindles ---{j 8 Spindles ---{j 4 Spindles ---{j 8 Spindles 8 --{j 4 ---{j Spindles Spindles Application programs-nsurance company The system employs 6 different application programs which can be classified into four categories. The first covers inquiry services, the second is registration of a new contract and its document issue, the third is continuance of a contract, and the last is the update of a contract. All categories but the first one require data base updates. New contract processing takes a particularly long time on account of many data base access calls (more than ten get, insert and replace calls) to four or five data bases. Five partitions where application programs run are reserved in the model, which means that a maximum of five application programs are simultaneously executed. Results-nsurance company We simulated 15 production runs with different message traffic, message scheduling strategies (concurrent DB access checks), application programs and number of partitions for application programs. Three results selected among those provided by these runs are shown in Table. Result 1 based on the system environment explained above tells that the system failed to process the traffic of 1 messages per hour (response time, its standard distribution and current contents of scheduling queue). The causes are neither hardware equipment bottlenecks (CPU, channel and disk utilizations) nor a task bottleneck (number of concurrent TABLE -Simulation Results Message Traffic (Msg./hr.) Average Response Time (sec.) Standard Deviation of Response Time (sec.) CPU Utilization (%) Max. Channel Utilization (%) Max. Disk Utilization (%) Average Number of DB l/os (jtrans.) Current Contents of Scheduling Queue (Trans.) 131 Average Number of Concurrent AP Tasks Clock Value in the Model (sec.) Simulation Time (min.) o

6 464 National Computer Conference, 1975 AP tasks) because there can exist five application program tasks at a time. The real bottlengck lay in the area of concurrent data base updates. All application programs except inquiry services issue data base update calls and if they are going to update the same data bases, only the message which has the highest priority is scheduled, while other messages remain in the scheduling queue even if all other partitions are empty. n this case, application programs of three categories update the same data bases, and the new contract processing has the highest priority and the heaviest load of all as mentioned before and accounts for a quarter of the message traffic, Which means that messages belonging to the other two categories can hardly be scheduled. Actually we found, by checking the scheduling queue, that these messages had waited over 7 seconds there when the simulation stopped. We suggested to the system designers to eliminate on-line updates in the new contract processing and to maintain data bases in batch mode or batch message processing mode. Result 2 shows how the new contract processing without data base updates improved the response time. There is no performance problem at all in Result 2. Result 3 tells that the modified system can easily bear the traffic of 15 messages per hour. Other results The following simulation results were obtained in a different system environment, which will not be explained in detail here. Figure 5 shows the relationship between data base buffer set sizes and the response time with message traffic as a parameter. The number of concurrent application program tasks is five, the block size of data bases is 35 bytes, and application programs retrieve a record randomly among all 2 Type of APs : nquiry Number of concurrent AP tasks: 5 Data base block size: 35 bytes ].B... i:i <l> l Number of physical data base l/os 21/s 41/s Type of APs : nquiry Number of concurrent AP tasks : 5 Traffic : 5 messages/hr o 4 Response time (sec.) Figure 6-Response time distribution (1) data base records. Figure 5 tells that buffer set size hardly affects the response time with low message traffic, more buffers are required as message traffic goes up, buffer requirement becomes saturated, however, and further buffers don't shorten the response time. The dotted line in the figure shows the minimum buffer set size required at each value of message traffic and we can see the necessary and sufficient buffer set size to contribute to the system throughput is 175 bytes which can contain five data base blocks, the same number as concurrent application program tasks. This is caused by the facts that a required record seldom exists in the buffer set because of random retrieval and the retrieval process needs one buffer at a time. Response time distribution with the number of data base l/os as a parameter is plotted in Figure 6. The effect of the number of data base l/os on response time distribution is dramatic. Figure 7 shows the response time distribution with physical block lengths of data bases, as a parameter, comparing the same block length with two kinds of block lengths in 15 rn. 1 1 Traffic: 14 messages/hr. Number of concurrent AP tasks : DB block size: 35 byte's / Average response time: 2.45 sec. " QJ) oj >...: data base buffer set size (K bytes) Traffic Figure 5-DB buffer set size vs. response time 172 Msg./hr. 14 Msg./hr. g88 Jg: , = Q) (J!-t Q) l. 2 / DB block sizes: 35 and 2 bytes Average response time: 4.82 sec Response time (sec.) Figure 7-Response time distribution (2)

7 A Simulation Model for Data Base System Performance Evaluation ' : Q) () 1-< Q) p., 15 1 DB block size: 35 bytes / Average response time: 1.49 sec. DB block sizes: 35 and 2 bytes Average response time: 1.64 sec. Traffic: 92 messages/hr. Number of concurrent AP tasks: 5 or fixed head disks-movable head disks) vs. system throughput We have collected and will collect the following data for tuning of the model. (a) Measurement of CPU dynamic steps and module activity by an instruction tracer. (b) Measurement of CPU, channels and disk storage devices activities by a hardware monitor. t includes data as described below in batch and on-line environment. o l o Response time (sec.) Figure 8-Response time distribution (3) the same system environment. Avera; ; response time in the case of two kinds of block sizes becl1ffies twice the one in case of the same block size, and the same trend exists for the deviation. The reason is that the buffer management module has the common buffer set for all data bases and manages it dynamically. More than one block size causes core fragentation and frequent requirements for garbage collectlon, which in turn increases the internal task wait time in the buffer management module. The effect becomes remarkable as the number of requests for buffer management increases with higher message traffic and/or frequency of data base /O requests per meassage. Figure 8 which curves were obtained under the same environment as Figure 7 except message traffic demonstrates this. We can see from the figure that there is no big difference between the two results when the message traffic is 92 messages per hour. CONCLUSON A simulation model which uses an event-driven type simulator was developed for the purpose of performance prediction of data base systems and research in the field of data base management system architecture. Several areas in which the model has been and is currently being used are as follows. Performance evaluation of an on-line design information system of a manufacturing company Evaluation of design alternatives of an on-line data base system in an insurance company Simulation of buffer management characteristics Simulation of concurrent processing Memory hierarchy of data bases (main memory-drum CPU active time, CPU active and supervisor state time Process steps, process steps in supervisor state Number of supervisor calls issued Channel busy time Disk seek time and count, search/read time and count, write time and count, RPS time and count. We finished measuring them, finished analyzing the results in batch environment and are currently analyzing the results in on-line environment. The model is reasonably accurate in batch environment. As this model uses an event-driven type simulator, real time/simulated time ratio is generally high (i.e., simulation cost is high). The value of that ratio depends upon the density of events (message traffic, number of data base access calls, etc.). From our experiment, the value is between 2 and 1. ACKNOWLEDGMENTS The authors wish to express their grateful thanks to Mr. S. Mimura and Mr. H. Sakai of the Software Works for providing us the opportunity of this research. We 91so would like to thank Mr. K. Arai and Mr. Y. Kasai for their suggestion and support concerning the simulation package. REFERENCES 1. Senko, M. E., E. B. Altman, M. M. Astrahan, and P. L. Fehder, "Data Structures and Accessing in Data-Base Systems," BM Systems Journal, No.1, Collmeyer, A. J. and J. E. Shemer, "Analysis of Retrieval Performance for Selected File Organization Techniques," Proceedings of the Fall Joint Computer Conference, Stimler, S. and K. A. Brons, "A Methodology for Calculating and Optimizing Real-Time System Performance," Comm. of the ACM, Vol. 11, No.7, Lum, V. Y., H. Ling, and M. E. Senko, "Analysis of a Complex Data Management Access Method by Simulation Modeling," Proceedings of the Fall Joint Computer Conference, 197.

8