in Database Management Systems

Transcription

1 A Framework for Monitoring Resources in Database Management Systems Allan M. Clark A thesis submitted to the Depanment of Computing and Information Science in conlormity with the requirernents for the ds=rcle of.masrsr of Science Quccn's Cniwrsity Kingston. ~ntari~. Canada Octobcr I99S Copyrisht :O Atlan M. Clark. 1998

2 National Library Bibliothèque nationale du Canada Acquisitions and Bibliog raphic Services Acquisitions et services bibliographiques 395 Wellington Street 395, nie Wellington OttawaON K1AW OttawaON KlAW Canada Canada The author has granted a nonexclusive licence ailowing the National Library of Canada to reproduce, loan, distribute or sell copies of this thesis in microform, paper or electronic formats. The author retains owership of the copyright in this thesis. Neither the thesis nor substantial extracts fiorn it may be printed or othewise reproduced without the author's permission. L'auteur a accorde une licence non exclusive permettant à la Bibliothèque nationale du Canada de reproduire, prêter, distri'buer ou vendre des copies de cette thèse sous la forme de microfiche/nlm, de reproduction sur papier ou sur format électronique. L'auteur conserve la propriété du droit d'auteur qui protège cette thèse. Ni la thèse ni des extraits substantiels de celle-ci ne doivent être imprimés ou autrement reproduits sans son autorisation.

3

4 This thesis presents a simple extensible frarnework for monitoring the state of a resource or system, originally designed to be used in punuit of Goal-Oriented Resource Management in the Quartemaster Project. We present sorne concepts of Goal-Onented Resource Management and performance monitoring as a grounding of Our research. We descnbe several existing monitoring taols and evduate their capabilities. Then we evaluate our framework as a tool using the same criteria, as well as those criteria described in performance monitonng. We show an exarnple of how to custornize the framework for a particular application, the bufferpools in DB21LIDB over a range of asynchronous VO Cleaners at saturation load. Finally. we summarize the research, and the framework. and we provide some insight as to the effect of VO Cleaners when DBWDB is at saturation load.

5 Acknow ledgments I owe my gratitude to my advisor, Dr. Pat Martin, who opened to me this horizon of research and offered a method of exploring it. His guidance, constructive cnticism, and patience helped me complete (finally) what I started. A sirnilar debt of gratitude is extended to J.P. LeBlanc for showing me what goals are possible, and how to achieve them. His particular form of encouragement and leadership provided renewed momentum when my own motivation was failing. I would be negligenr if I failed to thank my family. including its extensions. who supported me in al1 things prior to and during this work. Mixed feelings embrace this surprise. Finally. I'd like to thank the Database Lab and those friends who helped me finish. by providing the support, and often the diversions (*grunt*). when necessary. II 1 had not recrivcd the Microsoft Office pmduct for free. If I had püid anything for it. 1 would not have received rny money's worth.

6 Table of Contents 1. Introduction Motivation for Goal-Oriented Resource Management The Quartemaster Project Research Objectives Contributions..., Why a Framework and not a Tool? Organization of the Thesis Background and Related Work...* Existing Research on Goal-Onented Resource Management Evaluation of a Method Methods Dynamic Buffer-Pool Management (Dynamic Tuning) Fragment Frncing Clas Fencing Summary of Methods Meüsuremenr Theory Existing Monitorin~ Tools...* SC0 OpenServrr IBM DB2NDB v Windows NT Cornparison of Shortcomings Desired Monitoring Tool... 30

7 4. The Sarnpling Frarnework Design Constraints Conceptuai Overview Implementation Issues System Components Repository......, Samplerhpi SampIerFiler ListenerManager SampleListener The Client SamplerProxy SarnplerCacheProxy Evaiuation of the Framework I Experimental Environnient Evaluation of Overtiead Monitoring Example: I/O Cleaners and Bufferpools Experirnentation Modifications to the Sarnpling Fmmework Monitoring Resul ts Problems Encountered During Enperimentütion Sampiing Framework Evaluation Conclusions... 71

8 7. References..,..., vii

9 Glossary of Terms In any publication, the number of acronyms seems to be staggering at times. As well, an acronym usually has a totally different meaning to one reader as to another. For these reasons, I have included a list cf the acronyms used in this paper. DBA Database Adniinistrator - The individual charged with maintaining and improving the performance of one or more DBMSs DBMS Database Management System - The relational database, and the various tools and utilities to gauge its performance, modify its parameten, add or remove clients and rights, add resources, etc. DB2JUDB ibm DE32 Universal Database - The product we are using to evaluatc the framework is the commercial product DB2UDB by the International Business Machines Corporation. GUI Grriphical User Interface. Most commonly a pointer device and a number of windows, menus. buttons, icons. and lists selecttible with the pointer device.

10 JVM Java VirtuaI Machine - The abstractian between the Java process and the host hardware is a unifonn API and interpreter which makes al1 hardware look to be the sarne "machine". The JVM is a process which provides lightweight processes, memory-management, and V0 for its c hild processes. MIS Management of Information Systems - The person or group concerned with procuring, installing, maintainirig, upgrading, and disposing of information systerns and information techndogy as required. This usually includes the persona1 desktop cornputer allocated to an employee yet owned by the Company. MPL Multiprogramming Level - My understanding is that this is the maximum number of system processors which can be used at once by the database. Usually, this is a single number for the entire system, but in [Il, a per-class MPL is used for testing. RDBMS Relational Database Management System Santa Cruz Operatim. Inc. Commercial producers of Intel-bsed Unix operating systems.

11 1. Introduction The process of tuning a complex system, such as a database management system (DBMS), is an inexact science. It is e repetitive series of sample, analyze, calculate, and adjust operations. in addition to the human error that may occur. there are other drawbacks to this method: irregular sarnpling intervals, changing workload, and decisions based on the database adminisrrator's (DBA's) instinct which may prove to be wrong. Many times the information is simply not available to make a sound judgment 1 a failure of the tools available - which leaves the DBA with no alternative bu& to rely on instinct. As well, a database rnay have a workload that constantly shifts from one area (such as invoicing) to another (such as shipping and receiving) or from one class (simple updates) to another (data mining for trend-analysis). A DBA rnay not be able to reconfigure the DBMS quickly enough to offer its maximum throughput to its clients. The approach wc support in this thesis is to devise methods to allow the DBMS to optimize itself in an attempt to meer abjectives defined by the DBA. The system attempts to meet its goals through the rnethod of Goal-Oriented Resource Management. As we explain later in detail, Goal-ûriented Resource Management is n process by which a systrrn rvaluates its perrurmance and seeks to continually irnprove upon this evrtluation[ I SI. It evaluates its performance in terrns of the degree to which it has met its goals. evaluoted in terrns of current load and resources. By changing one or more attributes and re-evaluating, a complex system seeks to attain d l of its goals; if the load and resources change, the DBMS indirectly responds to the change.

12 To some extent. our research on ~his project has been hindered by the same shortcomings in the available tools and utilities which make the administrator's task so diffmxlt at times. Using current tools, an accurate picture of the behavior of some attributes of the resource under inspection will materiaiize. Often, there is not enough pertinent data to make an accurate judgment, even when the administrator cm make solid decisions as to how to modify current resource configurations. In many cases, tools seern to cover most requirements. but not ail. or not in quite the same representation, that is, there is a different coverage by each tool. Even a poor representation would be suitable if a11 monitoring toois adhered to e standard rnethdd cf presentation. but monitoring different resources necessitares learning a whole rlcw tool for each resource. At this point, we should be pursuing ii better tool to gain an understanding of the less-obvious factors and correlations that may exist. By providing a better interface to analyze current attributes and performance. we can provide the researcher with the means to gain an accurate insight into the performance gained or lost by implementing certain methods of Goal-Oriented Resource-Management. 1.1 Motivation for Goal-Oriented Resource Management The workload put onto ri database is continually changing. Databases are bcing used for more and more types of data, in ever-expanding realms of the business world. New data-types, multimedia storage and retrievril. and data wzirehousing çxtend the storage of the database. while new query types sucb as warehouse queries for trends and

13 multimedia requests for massive chunks of data push the performance level to the limit. The fact that these queries arict data-types can exist on the same database server adds to the strain, When the throughput of a database cannot match its requests. a compromise must be determined and the database must be tuned to favour certain clients and transactions. Currently, the task of choosing proc~ssor levels, memory management, file system management. scheduling of automated tasks. and other configurable options is done manually by the administrator. The administrator activates a merisuring tool, collects data, rnakes some calculations. changes some parameters, and collects some more data. Although the administrator can rnake certain inhlitive choices, in most cases, the "final" values for the parameters are often chosen through trial-and-error. "Final" is quoted. since no value can remain constant while the database's role changes naturally with changes in a company's working processes. changes based on the time of year. or changes in client demands. The DBMS must "flex" and adjust in response. The performance characteristics of a modern DBMS are contjgured by a set of parimeters. analogous to a set of adjustment knobs or wheels on n piece of physical machinery[3j. The knobs on a database control elernents of the DBMS such as tïiesystem space, memory usage, number ot siritultaneous clients, etc. These adjustments can be fine in gnnularity (number of bytes to occupy as needed when expanding disk usage of a table) or rather coarse (incrcae disk space of a table to 130% of its previous sizr).

14 The sheer number of these configurable parameters adds to the versatility of a database, yet increases the complexity of the administrator's job. For an automated tuning system. the number of "knobs" increases the difficulty of the tuning algorithm as much as it Gxs the administrator's task. Before an optimization algorithm crin decide how rnuch tri turn a knob to improve performance, it must determine which knob is the appropriate one to chcange. This is the more difficult question, as it plages many ddministrators as well. With many interrelated parameters. database servers are more prone to reconfiguration errors. Th2 concept of setting out a "target zone" that the results are required to meet. and have the databac seai-intelligently move in a pianned fashion to that "target zone". is the very obiective of Goal-Oriented Resource Management. It lets the server do the tedious work for the administrator. When en trring the corpnrate world. a strucrured resource-managemen t system such as a goal-oriented resourre-management system has certain desirable qualities. First, the Manasement of Information Systems (MIS) tearn of a Company cm set drfinite goals or criteria that the databuse is expected to mert. Secondly, after a DBMS augmentai with goal-oriented rpsoiirce msinagernen~ has stabilized to a steady-state, the MIS teaiii is able to report rxactly what performaiice is achievable for aii the capital committcd to thc DBMS - hardware and software. Concrete performance numbers can bc used in future financial considemtions. Deteciion of a performance degradation can be

15 reported in such a timely fashion that the MIS team is able to improve the DBMS or accept the reduced performance levels. As well, Goal-Onented Resource Management is not limited to the world of databases. Consider an Asynchronous Transfer Mode (ATM) switch that intuitively reallofates its resources based on the changing demands of its clients. A LJNIX system configured as a gateway or firewall could be directed to meet certain criteria of datatransfer rates, while canying on other lower-priority tasks. These two examples are just the edge of a vast field of applications for Goal-Oriented Resource Management. 1.2 The Quartermaster Project The Quartemaster Project explores the use of goal-oriented resource management to reduce the complexity of the re-configuration process into smaller. more manageable problems. Under the direction of Dr. Pat Martin at Queen's University, researchers in this project are attempting to define a system which suggests adjustments to existing resource levels to improve performance of DBUUDB. Goal-Orirntrd Resource Management transfers the work of optimizing ihc performance of a system from the sdminismator ro the system itself. The administrütor defines a set of Resource Manasement Policies[l8], which the system attempts to meet. These policics dcfine the performance objectives and the control "knobs" which cün bc adjustrd to nieet these objectives. Sornr examples of performance objectives are:

16 Deadline: a task or sequence of tasks mut be cornplete by a given time; Average Response Time: the average response delay to a group of users shouid be less than a given time; Percentile Response Time: a given portion of transactions should take less tirne to complete ihan a given delay; Service Rate Goal: fi. service rate of a group of services is acceptable if it is ailocated a given portion of resources The project defines an abstraci hiewchy of manager processes such that each resource is controlled by a specific local resource manager tailored to the resource. Each local resource manager uses its availabie monitoring capabilities to mesure the current performance and manage the configuration of the resource in an attempt to meet objectives. Each local resource manager is controlled by a more generic resource manager through which it receives policies and reports progress. All resource managers are controlled directly or indirectly by a global resource manager, which takes policy from, and reports progress to, the administntor. The Quartemaster project requires a simple inethod of querying state information from a nurnber of resources. it 2 sürnpling tool or libriry is generic enough. it can be used to draw state information from a number of resources with minimal resource- specitlc customization. A generic sampling frltmework cm also reduce the work necessary to rxpand the resource coverdge of the Quartemaster project as well. The resource managers require tirnely. accurate, detailed information pertaining to the state of 6

17 the resources they manage, in order to provide more accurate reconfiguration advice. Our goal, in pan, is the design of such a generic frarnework which can be extended to access an array of resources and provide dctailed information. Research Objectives In order to meet the above objective, we propose that a new kind of tool is required. We propose to build a sarnpling libnry or frarnework that offers a simple API from which to quickly build rnodular, adaptable sampling tools. If most of the work to create a sampling tool has been çompleted for the experimenter, she is not far from building her tool herself. In th;, manner, as the requirements of the sampling tool change. with minimal effort, she cm augment her toois so that they continue to give the most appropriate information. The original problem which sparked this project is the asynchronous V0 subsystem of the DB'JUDB[Wj D3A4S. The effect of the number of asynchronous VO processes is not qualitatively known. The task of monitoring the performance of this subsystem is an excellent demonstmion of the capribilities of the sampling fmmrwork. In this thesis, we present the underlying design, and implementation of the systern tools which are included in this research. As weli, we present the set of APIS offered ris a fr~mework to the drveloper. so thrit. if desired. he cao build tools which closely match thc requirements of the situation. Fintilly. as a proof of concept, we present ü sample

18 modification or customization to demonstrate the APT and tools, by sampling the performance of the D BWB DBMS asynchronous VO subsystem over a period of time. 1.4 Contributions The benefit of the work described herein to the study of Goal-Oriented Resource Management is two-fold. The bufferpool customization demonstrates that the framework can be directly used to help analyze future work in this area of study on the D B ~ D B database. As well, as the research continues, the framework can be later used to enhance the monitoring detail so that the effects of the research itself in Goal-Oriented Resource Management can be gauged. The Quartermaster Project, as we discussed earlier. has a requirement for accurate data of the inner status of the resources of a DSMS. This framework and API has been drvelopsd with the Quanemaster project as a possible irnplernentation. By relying on the srimpling framework, a god portion of the task of collecting data frorn a variety of resources is cornpletc In this fahion, the Quartermaster project gains another rnodular cornponent to augment its own strength. 1.5 Why a Framework and not a Tool? This question may be more effecctiveiy answered after the cornparison of some existing tools. as the answer will bzcome more obvious. Rather than provide the best tool

19 which covers the most attributes and is the most versatile, we opted to create the skeleton of the ideai tool. By giving developers the ability to quickly create and rnodify the exact tool they want, a more appropriate tool can be built where required. Just as the Ioading on shared resources changes, the capability to watch the exact set of indicators changes as weii. A framework with a simple APT is a more powerful investment in the long-term than a single, finished tool. 1.6 Organization of the Thesis We introduce this research by summarizing the pertinent background information. This serves to introduce the underlying concepts and to give the reader an idea of the objectives we intend to satisfy. Ué present a number of existing monitoring tools. from which we draw a nurnber of str~qgths and shortcomings to address in our own work. We continue by presenting the high-level overview of the framework we have built, which may serve to prepare the reader Cor the in-depth review of the different classes which follows. We evaluate our tool using the same citena used to evaluate those existing tools. then we demonstrate the too! by customizing it towards some DB21LIDB sampling aimed at a better understanding of the tisynchronous wnting processes of DBaUDB.

20 2. Background and Related Work A significant demand for this research has ken expressed by those researching Goal-Oriented Resource-Management at Queen's University. Current work invoives a number of methods by which a system cm allocate resources to optirnize its overall performance based on pre-determined criteria The framework we use to complete our own monitoring is based on sampling. The accuracy and confidence of samples needs to be undentood, so a general discussion is included. Although no modifications of rhe framework are explicitly used to show or guarantee accuracy or confidence. impkmentation of a performance gauge as a usercomponent would not be excei~ively difficult (except for the summation under the normal curve, as discussed in section 2.2) 2.1 Existing Research on Goal-Oriented Resource Management Goal-Oriented Resourcr Ilianogement is the process by which a rrsource is op~imized by an autonomous process in an attrmpt to meet or exceed goals defined by the adrninistrritor of that resource. The reasons for irnplementing such a system are nunirrous. as we have touched upon already. There are a number of methods currently being researched, but their application to a specific task cannot be evaluated without a concrets method of cornparison. We start by presenting the criteria upon which we 10

21 evaluate a method, then we present a number of recent methods of goal-oriented resource management with intent to display the depth of knowledge required to gauge the performance of a resource, Evaluation of a Method The most important conîidention for a system which optimizes itself is how to evaluate its performance. The systçm has to be able to tell, without extemal expertise (such as the DBA) whether its perforn-lance has improved. To be considered acceptable, a system of optimization (its algori thms and processes) must address the following abstract issues[3] : Accuracy The system should achieve performance close to its specified goals. A common measure of how well a system does this is a "performance index"[4], which is a simple ratio of (observed performance) I (performance goal). This yields an index less than I for a performance not achieving its goal. whereas- a performance index greater than I is a goal achieved beyond oxpectations; an index value of 1.O is ideal. Responsiveness The system should achieve a steady-state configuration with a minimum number of changes to the various control knobs. Responsiveness is inverseiy proportional to the number of changes ri database makes tn its configuration to achieve the steady-state condition.

22 Stability Stability is a measi?re of how much the system changes to refiect the changing workload. If there is no sigiificant change in the workload, then the responsivenzss of certain classes cf transactions should not change significantly either. Overhead The cost in terms of systez.1 resources to use an optimization method should not significantly impact the general efficiency of the system. Brown[3] suggests csing the response time of a "best effort" or "No Goal" class on a self-;ming database venus the same database without the optimization metlod to gaug the overhead of the optimization processes or algori thms. Robustness The optimization rilethod should not try to optimize a class of transactions by chünging a control knob that has little sffect on the perfomance of the class. For instance, in a multimedia load, the data is in large chunks so disk pre-fetching of adjaceht data will affect performance, but MPL will have no effect. The system should not try to optimize this ciüss with a change to any MPL characteristics for this clas. Logically. until ri systern has become "acquainted" witn a workload. it will not know which controls modi fy i ts performance.

23 Practicality The optimization method should not overly constrain the system's basic functions (disk updating, page swapping, fetching) nor should it place unreasonable constraints on the operating system. These attributes should be niostly orthogonal. Although they describe mutually exclusive features, they may iiidirectly affect each other. For example, increased responsiveness can reduce siability and increase cverhead. It is impossible for these attributes to be cornpletel y unrelated since their natxe suggests a slight interconnection. It is obvious that any operatiiip state is the result of a compromise of two or more attributes Methods In this section. we present three rnethods. Drawing mostly on the research of Brown[3], 1 will relate the basic concepts of each. Note that Class Fencing is a relatively new method. so little discussion wÿs available pertaining to its design. While reviewing each method, it is important to note the detail of information required by each method. The Quafiermaster projec: and research at Queen's University ha concerned itself recrntly with the resource management of bufferpools in the DB2NDB database server. As we mentioned rarlier, the asynchronous reaarrs (prefetchers) and writers (VO clsaners) greatly affect performance. so they have corne under scnitiny. We require a

24 very clear understanding of the state within the DBMS in order to decide how to improve the current performance, and to evaluate Our own work. The following sections briefly enplain some of the details of three methods which are prevalen t in goal-oriented resource management. Each method assumes a detailed, intimate knowledge of the internai state of the monitored system. We must know when we have exhausted our resourceh, and why Dynarnic Buffer-Pool Management (Dynamic Tuning) This method is descnbed by Churig et al[2]. The overall goal is to balance Performance Indices of al1 classes of transactions ir, the database by shifting buffers from the pool of the class with the brai performance to the pool of the class with the worst performance. In this sense, a "class" of transaction is an arbitnry grouping of transactions into a comrnon piüfile - data mining as opposed to simple queries. for example. The assurnption is made that performance is directly related to the average cost of moving a page to memory from disk if it is not already in rnemory. This method uses a Hit-rate aigorithrn[3] to predict mernory requirements bsed on türget hit-rates (from [3]): R "'. R "'= (1.0 - HE"' (M)) x D = estirnated response time HIT"'-(M) = rstimated hit ratio with a rnernory dlocation of M D = cost ol' moving a page from disk to rnemory

25 For each class of transactions, a required target hit-rate is caiculated to increase or reduce the Performance Index. The hit-rate algorithm is used to estirnate the necessary buffer space to achieve this hit-rate, and therefore to achieve the desired performance index. The estimation of the desiied memory pool size is done, as mentioned, by the hitrate algorithm above. The mosc recent two values for the hit-rates at given memory sizes are insened into the equation. and it is -olvsd with boih values simuitaneously to provide a bais for Further prediction. Then, by inverting the hit-rate algorithm. we get a "curve" of possible hit-rates and memory values. The desired hit-rate is insened in the inverted equation, and the resulting memory-pool size which will yield this goal is determined. The calculation of target mernory allocations is carried out for al1 classes of the database. Once target memory allocations are calculated, mernory is added (subtracted) to (from) each pool frorn (to) a cuminon pool. Each pool is managed independtntly from this point by mutually autonomous memo-sr managers, so that each pool is managed in isolation. The equation usrd to predict memory requirements is relatively simple. The equation can bc converted tu ri matrix caiculation, which can be caiculatcd with the rnost- reccntly siimpled values fil led in. Althuug? a tinie-consuming calculation. it is not done

26 often - the database system c m afford a complicated caiculation when recalculating its tuning values. Brown[3] points out that the Hit-Rate algorithm used for dynamic tuning is a good approximation of a generic hit-rate. It does not, however, accurately mode1 any parricular class of transactions. Brown shows in [3] how the hit-rate algorithm consistently under-estimates performance. which is a safe assumption, but not optimal. A safe assumption is probably acceptabl-2 if there is only one "class" of "transactions". such as swapping memory to dkk to create vinuai memory, the original intent of this algorithm. The constant under-estimation leads t~ many classes in the sarne database which have slightly more memwy than they require. This rnay keep another class that is performing very near to its goal Îrom achieving its goal. due to the memory wasted by inaccurate predictions Fragment Fencing Fragment Fencing assumes tht response tinte is directly proportional to memory hit-rate. which is similür to Dynüixic Tuning's assumption that performance is inversely proportional to the cost of moving ri chunk of data from disk or mernory. Although there are many other variables involved in response times (CPU load, process priority, process swapping, etc.) in a systern bound mostly by disk access, these other factors becorne tess significant. The estimation of a hi<-rate to achieve a certain response time goals is as follows [3]:

27 rn = (M obsv (R gd / R Obsv)) E.IIT = target hit rate estimated to reach response time goal M O ~SV R = observeci miss rate for the observed response time = response time goal R obsv = observed response tirne Fragment Fencing goes to a deeper level of detail in its estimates; rather than estimate a class-wide hit-rate. it goes on to estimate a hit-rate for each fragment within a class. A fragment is defined as a11 of the pages that make up a single relatively uniform reference unit[3] such as a single relation, or a single level in a tree-structured index. A similar uniform reference pr~bability is assumed across ail pages of the fragment. therefore the percentage of the fragment that is memory-resident should yield the hit-ute of chat Fragment. The goal cf Fra~ment Fencing is to determine the "target residency". the minimum footprint in memory of a fragment to echieve a certain overall hit-rate for a class. Fragment Fencing rmploys a ranked system of increasing or decreasing the hitrate of a class. Al1 the fragments of a chss Ire rünked iiccording to their access frequency I size. If the hit-rate requires an increase in target residencies. the list is processed from highest to lowest, each fragment increased to 100% residency, until the hit-rites of the Fragments total up to the desirsd hit-rate. If a reducticn is called for. the list is processed