Real-Time TransaCtions with Execution Histories ... - ACM Digital Library

Real-Time TransaCtions with Execution Histories: Priority Assignment and Load Control * Giiltekin &soyo~iu

Erdoean Dogdu

Department of Computer Engineering and Science Case Western Reserve University Cleveland, OH 44106 {dogdu.teldn] @ces.cwru.edu http://erciyes.ces.cwm.edu/{dogdu,tekin}

Abstract In this paper, we consider new priority assignment and load control policies for real-time transactions. We assume that execution histories of transactionsunder different load conditions are available, and proposea numberof priority assignmenttechniquesbased on execution histories and evaluate them through simulation. A widely used priority assignment technique, Earliest Deadline First, is shown to be biased towards scheduling short transactions favor-

ably. We introducethe notion of “fairscheduling”of transactionsin which the goal is to have “similar”successratios for at1transaction classes (short to long in sizes).

1

Introduction

In this paper, we consider real-time transactions with execution histories. Such real-time database systems [CHJ94, HJC93, Sop961 exist in manufacturing, command and control systems, where certain database transactions are executed repeatedty, but not necessarily in a periodic manner. In this paper, we propose a number of priority assignment techniques utilizing the execution histories of transactions. Previous work on real-time databases focused on priorityassignment techniques for scheduling transactions. Most performance studies use the Earliest-Deadline-First (EDF) policy for priority assignment. EDF assigns a higher priority value to a transaction with an earlier deadline. Although EDF has been shown to improve the average success ratio of the system (fraction of transactions completing successfully within their deadline), it discriminates against longer transactions under overload conditions [HLC91, PLC92J. We propose priority assignment techniques that consider the biased nature of EDF, and attempt to eliminate the discriminatory behavior by adjusting the priorities using execution history information. Two basic pieces of data that is This research has been partially supportedby the National Science Foundation grant IRI-92-24660. E.Dogdu has also been supported by a scholarshipfmm the Ministry of Education,Turkey. l

lkrnksion IO m&a digikNhsrdcopir~ol'all or patiol‘ihis mr~wiel Jbr pwsonnl or classroonl use izgmntcd withoatIixprovidedIIKUlhetopic?; nrc1101 mnda or distributed forprolit or conwwcirl advantage. 111~ copyrigllr notice. IINGllcol'llle puhlicalion and itsdaleappear.and noke is givenlhntqyriglil isI?\puniision ul'lhl: ACM Inc.To ~wpy okxk. IO r~qwblish. IO poflon serwx or torr‘dislrihulr: IO litin rqoirLxspccilic penikki nndkw fee CIEM

97

Lnsl ~gm

.vf!lwf/~ 1x.1

Copyrigl~l I997 ACAI (J-8979I-970~~97 I I .$X%1

301

kept in transaction history logs are the transaction completion ratio and the transaction completion time. The completion ratio of a transaction is the fraction of successfully completed executions out of all executions of the transaction. Priority assignment techniques based on completion ratios of transactions assign higher priorities to transactions with low completion ratios such that the completion ratios of such transactions can be improved in successive runs. We call this approach “fair scheduling” where the goal is to obtain “similar” completion ratios for repeating transactions. The other group of priority assignment techniques utilize the completion time of a transaction. In this approach, the probability of completion for a transaction within a given time quota is estimated using the completion time history (mean and variance), and transactions with lower completion probabilities are assigned higher priority values to adjust the bias towards short transactions. Haritsa et al points out WC911 the need for load control in RTDBMSs. EDF policy, by assigning higher priority values to transactions with earlier deadlines, determines the execution order of transactions. However, under overload conditions, the performance of the system degrades due to assigning higher priorities to transactions that are close to missing their deadlines since those transactions delay other transactions that may otherwise be able to meet their deadlines. Haritsa et al proposes the Adaptive Earliest Deadline (AED) priority assignment algorithm for priority assignment as well as for the load control of transactions. In this method, a number of transactions are chosen to have the highest priority values (hit group). Using a feedback mechanism, the capacity of the hit group is adjusted dynamically to improve the performance. AED is later improved [PLC92] to Adaptive EarIiest V&al Deadline (AEVD) policy using a similar technique. Datta et al [Dat96] addresses some of the weaknesses in AEVD, and proposes the Adaptive Access Parameter (AAP) method for the explicit admission control. In this paper, we propose admission and load control techniques for scheduling repeating transactions based on execution histories. Admission control algorithms we propose are based on the ‘risk of overspending the time quota”. A dynamically adjusted system risk bound variable is used in

.

Load control in this system is done by changing the system risk bound variable value depending on the system performance. To our knowledge, our work is the first report on the utilization of execution histories of real-time transactions for priority assignment and load control in RTDBMSs. in the next section, we model the transaction processing environment we are deaiing with. In section 3, load and execution history-based priority assignment techniques are proposed. Section 4 deals with the admission and load control strategies for real-time transactions with execution histories. Preliminary simulation resuIfs are presented in section 5.

deciding the admission of new transactions.

2

Modeling the Environment

Here we use the term transaction for a program or a script that contains control statements and operations on a database system. Database operations are read and write {update) actions on data elements (recordffile or objectiobjectbase) from a disk containing these data elements. We assume that data elements are brought to the work area of a transaction block by bIock. Therefore, we assume that each database operation possibly involves a disk bIock access. 2.1

0 Number of Transactions: When transactions are of equal (or close to equal) sizes, the number of transactions running in the system can be a metric to measure the system load. But if the transaction sizes vary a lot (from very short to very long transactions), then the number of transactions by itseIf cannot reflect the real system load.

i ~

’

(

” { --’ :: ,I . l

;,

t

.;

1

.

;

.I ,I,

,,

l

Base Execution Ties: Base execution time of a transaction is the totaI time spent on CPU execution and disk accesses. The sum of base execution times {sizes) of currently running transactions can be used to define the system load. Since transaction sizes may vary from one execution to another, the expected execution times can be used to characterize the system load.

l

Resource Utilization: CPU and disk are two system resources used by transactions in paraIIeI. For most cases, a disk access usually takes a longer time than CPU processing time due to disk access latencies [i.e., seek, rotational delay, and data transfer times). Therefore, the sum of disk access time requirements of all transactions at a time can be used as part of the system load characterization.

.; :;

..

1 i

,’

Transactims:Tl,T2 Priorities

In RTD3MSs, priority-based scheduling is commonly utilized to improve she system performance (which is usually the success ratio). Then the real system load relative to an arriving transaction actually depends on those transactions with priorities higher than the priority of the new transaction. Suppose that there are n - 1 transactions in the system, the

: p1

< pz

,...,
_

.,“j;

,.‘,

E

‘1 :

,

‘;

,.._ ‘.. ,-, .. ,

J,

‘,,,

’

’ I

transaction with a low completion ratio should bc assigned a higher priority so that it has a higher chance to complete bcfore its deadline. Thus, PriOriig(Tj) = 1 - C,. B. High-Completion-Ratio-First (HCF): Transaction priority is assigned as Pra’ority(Ti) = Ci. This policy assigns higher priority values to a transaction as the completion mtio of the transaction gets higher. The idea is to give prcference in scheduling to transactions that are more likely lo complete. But, it is an unftir scheduling practice, favoring always transactions with higher completion ratios. Ncvcrtheless, it may improve the overall system performance by increasing the average success ratio of the system. C Low-Completion-Ratio and Earliest-Deadline-First (LCEDF): A combined priority assignment policy based on the LCF and the EDF policies can be used as where Ci the completion rnPriority(Ti) = l/(C&) tie of transaction Ti, and Di is the deadline (release time plus time quota) for Ti. This policy actually assigns priorities based on deadlines, but adjusts them by the completion ratios of transactions.

the ratio of the number of successful runs of Ti to the total number of runs of Tie The goal in fair scheduling is, then, that transactions should have “similar” completion ratios at all times. To evaluate the system utilization, we also measure the system resource utilizations (for CPU and disk separately). A resource’s utilization is found by the ratio of the sum of the total time that resource is used by aborted transactions to the total time the resource is used by ali transactions. This ratio is the wasted time ratio of the resource. A higher value then implies underutilization-

j

Assigning Priorities

In RTDBMSs, transactions are assigned priorities to ensure their timely completion before their deadlines. In accessing system resources (CPU and disk), high priority transactions are given precedence over low priority transactions. And, in the case of data conflicts, high-priority transactions again take precedence over low-priority transactions sometimes by aborting Iow-priority transactions. Various priority assignment policies are proposed and evaluated extensively in the literature. Earliesf Deatihe First (EDF) is the most widely used policy. In section 3, for ‘fair scheduling” of repeating transactions, we introduce a number of new priority assignment policies. In EDF, the transaction deadline determines the priority; transactions with earlier deadlines are assigned higher priorities than transactions with later deadlines. Priority of transaction Ti is set as Prkity[Ti) = l/Di where Di is the deadline of the transaction. Considering that high priority values mean precedence in scheduling, in this policy, a transaction with an earlier deadline is assigned a higher priority than a transaction with a later deadline. In the next section, we propose new priority assignment techniques that utilize the load and execution histories of transactions.

is

3.2

< I

!

: i

I,’

?

‘I .,

_!

,I,

‘.

ii

‘,,

.’

’ ._

,. ,.

3

,

;.,-.;

.,.

.

. .?.

. . I.

.,*

.L

i

‘i,1::1;

1

---,*

-I

‘,t;$

_, :-

3

t .’

,,

~,_

;.

‘,

s. I

‘.

i

I

.)

*,

.(

Load- and Execution-History-Bad Priority Assignment Techniques

.-

$

‘;‘.,

1

‘,, ,.!

Here we first consider an environment where a “repeating” transaction comes with the same time quota in every turn,, or the time quota of a transaction is rarely changed, or slight changes are made on time quotas. Such an environment with transactions having the same fixed time quotas is common in manufacturing databases and command control systems. Therefore, a real-time database system serving in such systemsis asked to carry out certain tasks within certain time Iisnits. A transaction is considered to be completed successfully if it runs and commits within its deadline (i.e., firm deadline). 3.1 Basic Techniques A. Low-Completion-Ratio-First [LCF): For fair scheduling of repeating transactions over a period of time, the transaction completion ratios of transactions can be considered. A 304

Load-Variant-Low-CompIetioll-Ratio-First (HIAX): using His@rams

In varying system loads, the completion ratio of a transaction changes- A transaction may complete its execution when there are only a few non-competing transactions, but may always fail when the system load is high. Thcrcforc, execution histories based on different system loads shoutd be considered. We assume that L’histograms’*are maintained in the system to keep track of successful completion ratios of individualtransactionsin different system load conditions. A histogram for a transaction Ti captures the conlpletion ratio ofTi (a value between 0 and 1) in different load conditions. System load at a certain time is characterized eilhcr by the sum of UO requirements, or by the sum of CPU rcquircments (depending on application-specific transaction characteristics) of all currently running transactions as discussed in the previous section. The system load histogram of a transaction keeps the completion ratios for system load intervnls, instead of eachdifferentsystem load condition. 11is expected that the completion ratio drops as the system load increnscs. The expected completion ratio of a new coming transaction Ti is then found from the execution histogram of the tran~action by the function CR(Ti,L) where L is the system load value at the time of arrival. Earlier proposals for priority assignment in RTDBMSs, such as the EDF policy (section 2,4), consider transaction deadlines. Even though the EDF policy improves the system performance by increasing success ratios, it may discriminate against long transactions by favoring short trnnsnctions @lLC9f, PLC92J. We want the system to schedule repeating transactions fairly by favoring transactionsthat hnvc lower completion ratios (known from execution histograms), To : do this, transactions are assigned priorities based on their ; ,

-ye .
-95 should hoId, where Prob denotes the probability. Then, pi+Z-&