Controlling the Behaviour of Database Servers

Controlling the Behaviour of Database Servers with 2PAC and DiffServ Luís Fernando Orleans1, Geraldo Zimbrão1, and Pedro Furtado2 1

COPPE/UFRJ - Computer Science Department - Graduate School and Research in Engineering – Federal University of Rio de Janeiro 2 CISUC – Department of Informatics Engineering – University of Coimbra - Portugal {lforleans,zimbrao}@cos.ufrj.br, [email protected]

Abstract. In order to avoid stress conditions in information systems, the use of a simple admission control (SAC) mechanism is widely adopted by systems' administrators. Most of the SAC approaches limit the number of concurrent work, redirecting to a waiting FCFS queue all transactions that exceed that number. The introduction of such a policy can be very useful when the most important metric for the system is the total throughput. But such a simple AC approach may not be sufficient when transactions have deadlines to meet, since in stressed scenarios a transaction may spend a lot of time only waiting for execution. This paper presents 2 enhancements that help keeping the number of transactions executed within the deadline near to the throughput. The enhancements are DiffServ, in which short transactions have priority, and a 2-Phase Admission Control (2PAC) mechanism, which tries to avoid the previousmentioned problem by limiting the queue size dynamically using informations provided by a feedback control. It also introduces the QoS-Broker – a tool which implements both SAC and 2PAC – and uses it to compare their performances when submitted to the TPC-C benchmark. Our results show that both total throughput and throughput within deadline increase when the 2 enhancements are used, although it becomes clear that 2PAC has a much bigger impact on performance than DiffServ. Keywords: QoS, DiffServ, Admission Control, 2PAC.

1 Introduction Congested request processing systems lead to degraded performances and quality of service. So far, a Simple Admission Control (SAC) was sufficient to avoid stress conditions on database servers. All incoming transactions that would make the server exceed the allowed multi-programming level (MPL) [17] would be directly forwarded to a FCFS queue and wait there for future execution. Although this is a fair approach, where all transactions are served in their arrival order, it is hard to be applied if transactions have deadlines to meet. Intuitively, as the transactions arrival rate increases, the number of transactions that will be redirect to the waiting queue will also increase, hence the time each transaction will spend waiting for execution. The inclusion of S.S. Bhowmick, J. Küng, and R. Wagner (Eds.): DEXA 2008, LNCS 5181, pp. 779 – 790, 2008. © Springer-Verlag Berlin Heidelberg 2008

780

L.F. Orleans, G. Zimbrão, and P. Furtado

time-constraints in database transactions makes the traditional admission control implementations unable to reach the QoS conditions that might be established between the service provider and the service contractor. This way, another admission control layer is necessary: one that should try to avoid the uncontrolled growing of the queue, creating what we called a 2-Phase admission control (2PAC). In this paper we propose the 2PAC policy , which learn workloads patterns and adapts the queue size to provide much better guarantees than SAC. Our proposal also handles efficiently transaction heterogeneity: we also propose a DiffServ enhancement to the basic 2PAC proposal, which prioritize short transactions by preventing them to pass through any of the admission control layers when it makes sense, boosting the performance. Our experimental work compares SAC, 2PAC and 2PAC plus DiffServ, using the TPC-C benchmark. We do not cover a best-effort configuration, since it had been already extensively studied. Two scenarios were created: a high load scenario and a medium load scenario. Both will be explained in deeper details later. The 2PAC has better throughput than its competitors in all cases, having a small fraction of accepted transactions breaking their deadlines. The main reason is the second admission control phase, which tries to optimize the queue size according to the transactions previous durations. This way, all transactions that presents high response times that would probably miss their deadlines are rejected by the middleware. The remaining of the paper is organized as follows: section 2 lists the related work. Section 3 gives the background in which this work stands for. Section 4 presents the 2 Phase Admission Control algorithm and section 5 explains how a DiffServ mechanism can be used within a database context. Section 6 gives the experiment setup, while section 7 lists the results obtained from those experiments. Finally, section 8 concludes the paper, also proposing some future works.

2 Related Work In [6] the authors propose session-based Admission Control (SBAC), noting that longer sessions may result in purchases and therefore should not be discriminated in overloaded conditions. They propose self-tunable admission control based on hybrid or predictive strategies. Reference [5] uses a rather complex analytical model to perform admission control. There are also approaches proposing some kind of service differentiation: [3] proposes architecture for Web servers with differentiated services. [16] proposes an approach for Web Servers to adapt automatically to changing workload characteristics and [9] proposes a strategy that improves the service to requests using statistical characterization of those requests and services. In [15], it is proposed a dynamic load-balancing algorithm, called ORBITA, that tries to guarantee deadlines by applying some kind of DiffServ, where small tasks have priorities and execute on a dedicated server. The big tasks have to pass through the admission control mechanism and can be rejected, if the maximum MPL (calculated in runtime) had been reached. Comparing to our own work, none of the previously mentioned intended to study how to manage the growth of the waiting queue, which has its size dynamically

Controlling the Behaviour of Database Servers with 2PAC and DiffServ

781

computed according to the workload characteristics, in order to accept only the tasks that will be able to execute within the deadline.

3 Background This section provides the necessary background for the complete understanding of this work. 3.1 Simple Admission Control (SAC) The SAC architecture is presented in figure 1: all incoming transactions that would exceed the MPL wait for execution in a FCFS queue. Every time a transaction is committed, it leaves the system and another one is picked up from the queue. Reference [17] presents the architecture illustrated in figure 1, and proves that the near-to-maximum throughput can be achieved with a relatively low MPL. The work proposed by [15] shows an interesting mechanism that tries to avoid deadlines from being broken. Although that study is about load-balancing, a theme that is out of the scope of this paper, it guided our work as it dynamically compute the size of the request and calculate the appropriate MPL.

Fig. 1. Standard admission control components. A waiting queue and a fixed number of concurrent executing transactions, also known as multiprogramming level (MPL).

3.2 TPC-C Benchmark The TPC-C benchmark (http://www.tpc.org/tpcc/) is a specification provided by the Transaction Processing Performance Council that simulates a real-world database application using a closed-model, where the number of clients is fixed and each transaction submission is followed by a “think time”, which is responsible for simulating the time a user spends analyzing the last request before sending a new transaction. When the think time assumes lower values, the load on the system increases, causing a stress scenario.

782

L.F. Orleans, G. Zimbrão, and P. Furtado

3.3 QoS-Broker The Qos-Broker middleware [10] is a tool that intercepts the conversation between an application and a database server. It uses the Proxy Design Pattern to provide a transparent admission control layer, without requiring deep source code modifications. As all the SQL statements go through the Proxy, it is possible to calculate the mean time each transaction type takes to execute. It is also possible to keep a list with the used transactions as well as to classify the transactions in read-only and update transactions (which comprise insert, update and delete SQL statements). For each transaction, the QoS Broker is able to calculate the mean response time, thus providing an accurate way to estimate the queue waiting time and try to avoid the deadline misses. The QoS-Broker can be configured to use both SAC and 2PAC, as well as DiffServ. If SAC is used, then the transactions that would cause system overload are redirected to FCFS queue. On the other hand, if the 2PAC flag is set, those transactions are enqueued only if the QoS-Broker calculates that they would be able to execute within the deadline – otherwise the transactions are not accepted. Finally, the DiffServ flag gives priority to short transactions.

4 Two-Phase Admission Control (2PAC) This type of admission control provides not one, but two layers of admission control. It controls the number of concurrent transactions executing (by checking the MPL constraint) and it also restricts the number of transactions on the queue. The 2PAC mechanism needs to know an estimation about transactions durations and, this way, it can calculate the time a transaction will have to wait on the queue and determine if it will end its execution before the deadline. To determine the acceptance of a transaction on the queue, the following constraint has to be satisfied: Texec + Tqueue < Tdeadline

(1)

Where Texec is the time a transaction will need to execute, Tqueue is the time a transaction will have to wait for execution and Tdeadline is the deadline time. The basic 2PAC algorithm is listed below: Algorithm 1: 2PAC

1. When a transaction tx is submmited by a client, calculate the estimated execution time for tx. 2. If the sum of estimated execution time of tx with the estimated time tx will spend on the queue is less than the deadline then tx is enqueued. Otherwise, it is rejected.

Controlling the Behaviour of Database Servers with 2PAC and DiffServ

783

In order to effectively calculate the estimated time a transaction spend executing, the QoS Broker middleware was improved and was added a feature that saves a pounded mean of past transactions for each type. The transaction´s mean duration is calculated as: E(N)=0.4*Tx(N-1)+0.3*Tx(N-2)+... +0.1*Tx(N-4)

(2)

Where E(N) is the estimated duration of the Nth arrived transaction, and Tx clauses are the real durations of the last transactions of the same type. Our formula uses the last 4 real measures to calculate the estimation, trying to obtain a mean time which reflects the recent behaviour of the database server. This way, 2PAC tries to avoid executing transactions that will possibly break their deadlines by rejecting them. It´s worth to notice that the rejection of a transaction does not necessarily imply on a real rejection: the transaction may be redirected to a lower priority waiting queue, and only execute when the other one is empty, for example. The last statement about the implementation of the 2PAC method on the QoS Broker tool concerns about the recognition of the transaction´s type in runtime. In order to reduce complexity of the implementation, the client is obligated to inform the QoS Broker which transaction he/she is about to execute.

5 DiffServ DiffSev is an acronym for Differentiation of Services. It is a fundamental building block for QoS networks in the sense that it gives some kind of priority to more critical packets, e.g., video or audio streaming packets. This concept can be applied also in information systems, where some transactions may be prioritized. According to the related work [15], in a distributed or parallel environment, it is feasible to give priority to short transactions without overwhelming the throughput of the big transactions. In this work, the short transactions can pass through the admission control mechanisms if the DiffServ flag is properly set. Intuitively, this can be a reasonable choice in a 1-server configuration only when the number of big transactions is much higher than the number of small ones – otherwise it can degrade the performance by letting lots of small tasks execute at the same time.

6 Experiment Setup All experiments were executed using a Pentium 4 3.2GHz, with 2GB RAM DDR2 and a 200 GB SATA HD which was responsible for creating the threads that simulate the clients. The server was a Pentium II MMX 350MHz, with 256MB RAM and a 60GB IDE HD. Both computers were running a Debian Linux, with Kernel version 2.6 and were connected by a full-duplex 100Mbps Ethernet link. A PostgreSQL 8.1 database server was running on the server machine and the database size was 1.11GB.

784

L.F. Orleans, G. Zimbrão, and P. Furtado

The client machine used a Sun Microsystems' Java Virtual Machine, version 1.5. The database was created with 10 warehouses, which allows a maximum of 100 terminals (emulated clients) by the TPC-C specification. 6.1 Workload Composition In order to effectively test the performance of the QoS-Broker, we used 2 transaction mixes and 2 load scenarios, leading up to 4 different workload compositions. The details of each are given below. The default transaction mix is the TPC-C default mix, while the heavy-tailed alternative depicts a typicall scenario where short transactions represent 95% of the system load, similar to the observations contained in [13]. Table 1. Transaction mixes Transaction Mix

Transactions Occurrences

Heavy-Tailed (used for comparison purposes)

Default

•

Delivery: 5%

•

Stock-Level: 95%

•

Other transactions: 0%

•

New Order: 45%

•

Payment: 43 %

•

Other transactions: 4%

Table 2. Think times Load Type

Think Time

Medium-Load

Exponential distribution, with mean 8 seconds and a maximum of 80 seconds

High-Load

Exponential distribution, with mean 4 seconds and a maximum of 40 seconds.

6.2 Other Considerations Each experience was executed for a period 20 minutes, and during the first 5 minutes no data was collected. Before each round, the database was dropped and then recreated, which guarantees that all experiments encountered the same database state. Finally, all experiments were made using 100 emulated clients. The TPC-C specification establishes 5 seconds as the maximum response time for each transaction – except for the Stock Level transaction, which has to be completed within 20 seconds. Our experiments showed that the Stock Level is the fastest transaction of the transaction mix, taking 70.35ms to execute in average, considering

Controlling the Behaviour of Database Servers with 2PAC and DiffServ

785

standalone execution (transaction executing on an empty system). We considered a 5 seconds deadline for all transactions, including Stock Level.

7 Results For the first round of experiences, a heavy-tailed scenario was used. The results are displayed in figures 2 and 3. Since the number of short transactions is much greater than the number of long transactions, no DiffServ was necessary. The first thing to be noticed from the graphics is that the throughput within deadline (TWD – number of transactions that ended within the deadline per minute) for the SAC case is much smaller than the total throughput (TT – total number of transactions that ended per minute) for the medium load case. For the high load scenario, the TWD is even worse: no transaction ended within the deadline at all! So it turns out the necessity of a new approach, one which tries to avoid deadline misses. The graphic in figure 2 shows the effectiveness of the 2PAC approach, since the TWD is always close to TT. In figure 3, we can see that the maximum throughput is reached with only 2 MPL by the system with 2PAC. This occurs because the workload is comprised mostly by short transactions, which execute very fast. As the MPL increases, the TT keeps almost unaltered, while TWD decreases. Two conclusions can be taken from the last statement: 1) 2PAC is more robust than SAC, since SAC has its performance deeply degraded by higher MPL values; and 2) the workload variability is responsible for the degradation of TWD of 2PAC in figure 3 for higher MPL values, since more long transactions get to execute. In the second round of experiments, we used the default transaction mix, established by the TPC-C specification. In this transaction mix, the number of short transactions is much smaller than the number of big transactions, so we used the DiffServ engine as another enhancement to the system. Figures 4 and 5 show the graphics for medium load and high load, respectively. Again, it turns out that 2PAC mechanism is

     

 !  

  

"#$% &%! "#$'(
#$% &%!
#$'(



    
























Fig. 2. Performance comparation in a heavy-tailed, medium-loaded scenario. SAC has a fewer number of transactions within deadline (TWD) than 2PAC.

786

L.F. Orleans, G. Zimbrão, and P. Furtado

 &%     !  

    

"#$% &%! "#$'(
#$% &%!
#$'(



    
























Fig. 3. Performance comparation in a heavy-tailed, high-loaded scenario. SAC has no transactions ended within deadline (TWD) whereas 2PAC scales very well.

    !  

    

"#$% &%! "#$'(
#$% &%!
#$'(
#$( ))"  % &%!
#$( ))" '(



    
























Fig. 4. Performance comparation in a medium-loaded scenario, using the standard transaction mix. SAC performs poorly whereas its competitors are able to handle a reasonable number of transactions without breaking their deadlines.

much more robust than SAC, which can be attested by the comparison of TWD of both methods: 2PAC's TWD is almost the same as TT for all MPL values, in SAC these values of TWD are very low (0 for the high load scenario). The use of DiffServ also increased the performance, but its contribution is smaller than the isolated use of 2PAC. Figure 4 shows that SAC has a very small TWD, due to the massive presence of long transactions, achieving its highest value (58 transactions per minute) with MPL 6. On the other hand, the 2PAC approach has as maximum TWD 414 transactions per minute, more than 7 times higher than SAC! When the DiffServ flag is set, then the TWD goes to 447 transactions per minute. The graphic 5 shows that no matter how the load on the system increases, the TT of all techniques remains almost unaltered. But, in SAC case, the queue grows uncontrolled

Controlling the Behaviour of Database Servers with 2PAC and DiffServ

787

 &%   !  

    

"#$% &%! "#$'(
#$% &%!
#$'(
#$( ))"  % &%!
#$( ))" '(



    
























Fig. 5. Performance comparation in a high-loaded scenario, using the standard transaction mix. Again, SAC has no transaction ending before the deadline was reached. The 2PAC approach has a better performance and the DiffServ enhancement represents a little performance gain.

* +  *       !  

  
#$  
#$ &%


  
























Fig. 6. Transactions rejection rate when 2PAC is used in a Heavy-Tailed scenario. As the MPL increases, the number of rejected transactions decreases.

and the time a transaction spends waiting for execution makes it miss the deadline. In fact, TWD is zero for all MPL values in SAC. Again, the 2PAC has a better performance, keeping TWD close to TT, reaching its maximum value at 14 MPL with 453 transactions per minute. With DiffServ enhancement, the maximum TWD is reached with MPL values between 8 and 12, with 474 transactions per minute. The graphics 6 and 7 compliment the last two providing informations about what makes the system perform so well with 2PAC: the rejection of transactions that would not be able to fully execute within the deadline. The rejection rate when DiffServ is

788

L.F. Orleans, G. Zimbrão, and P. Furtado

* +  *

  !  

,  
#$  
#$ &%
#$   ( ))" 
#$ &% ( ))" 

 
  
























Fig. 7. Transactions rejection rate when 2PAC is used in a TPC-C's default transaction mix scenario. Note that the use of the DiffServ enhancement is directly responsible for the fewer number of transactions being rejected.

used is smaller since there are no small transactions being rejected: they all go directly to execution. This reinforce the idea that there is no silver bullet to solve this deadline guarantees problem. If the system load is too high, then some of the transactions should be discarded since the system will not be able to execute them within the deadline.

8 Conclusions Stressed database servers may use an admission control mechanism to achieve better throughput. This becomes a problem when transactions have deadlines to meet as traditional admission control (SAC) models (with a FCFS waiting queue) may not be applied, since the queue time is a potential point for QoS failures. This paper presented the 2-Phase Admission Control (2PAC) model, which estimates the execution time of a transaction according to a mathematical formula that takes into account the last 4 execution times of the same transaction. Once the execution time is estimated, it is possible to calculate how long the transaction will spend on the waiting queue and, furthermore, if the transaction will be able to be completed before the deadline. If the middleware calculates that the transaction would miss the deadline, it is rejected by the system. Then, we compared the performances of both models (SAC and 2PAC), under medium and high loads and for both heavy-tailed and TPC-C's default workload. A last enhancement, DiffServ, was included in the experiments for the default workload. DiffServ gives priority for short transactions, letting them pass through the admission control mechanism. The results showed that, in order to reach a good rate of transactions ended within deadline, it is necessary to limit the number of transactions on the waiting queue. This way, all transactions that are supposed to miss their deadlines are rejected. Despite the

Controlling the Behaviour of Database Servers with 2PAC and DiffServ

789

high number of transactions being rejected, the improvement on system's performance is almost 8 times higher when both 2PAC and DiffServ enhancements are used. As future works, we intend to investigate how a multi-server environment is affected by admission control policies and try to establish a connection between them, leading to a complete highly scalable, distributed database system.

References 1. Amza, C., Cox, A.L., Zwaenepoel, W.: A Comparative Evalution of TransparentScaling Techniques for Dynamic Content Servers. In: International Conference On Data Engineering (2005) 2. Barker, K., Chernikov, A., Chrisochoides, N., Pingali, K.: A Load BalancingFramework for Adaptive and Asynchronous Applications. IEEE Transactions on Parallel and Distributed Systems 15(2) (2004) 3. Bhatti, N., Friedrich, R.: Web server support for tiered services. IEEE Network 13(5), 64– 71 (1999) 4. Cardellini, V., Casalicchio, C.M., Yu, P.S.: The State of the Art in Locally Distributed Web-Server Systems. ACM Computing Surveys 34, 263–311 (2002) 5. Chen, X., Mohapatra, P., Chen, H.: An admission control scheme for predictable server response time for Web accesses. In: World Wide Web Conference, Hong Kong (2002) 6. Cherkasova, Phaal: Session-based admission control: A mechanism for peak load management of commercial Web sites. IEEE Req. on Computers 51(6) (2002) 7. Crovella, M., Bestavros, A.: Self-similarity in World Wide Web traffic: Evidence and possible causes. IEEE/ACM Transactions on Networking, 835–836 (1999) 8. Dyachuk, D., Deters, R.: Optimizing Performance of Web Service Providers. In: International Conference on Advanced Information Networking and Applications, Niagara Falls, Ontario, Canada, pp. 46–53 (2007) 9. Elnikety, S., Nahum, E., Tracey, J., Zwaenepoel, W.: A Method for Transparent Admission Control and Request Scheduling in E-Commerce Web Sites. In: World Wide Web Conference, New York City, NY, USA (2004) 10. Furtado, P., Santos, C.: Extensible Contract Broker for Performance Differentiation. In: International Workshop on Software Engineering for Adaptive and Self-Managing Systems, Minneapolis, USA (2007) 11. Harchol-Balter, M.: Task assignment with unknown duration. Journal of the ACM, 49 (2002) 12. Harchol-Balter, M., Crovella, M., Murta, C.: On choosing a task assignment policy for a distributed server system. Journal of Parallel and Distributed Computing, 59(2), 204–228 (1999) 13. Harchol-Balter, M., Downey, A.: Exploiting process lifetime distributions for dynamic load-balancing. ACM Transactions on Computer Systems (1997) 14. Knightly, E., Shroff, N.: Admission Control for Statistical QoS: Theory and Practice. IEEE Network 13(2), 20–29 (1999) 15. Orleans, L.F., Furtado, P.N.: Fair load-balance on parallel systems for QoS. In: International Conference on Parallel Programming, Xi-An, China (2007) 16. Pradhan, P., Tewari, R., Sahu, S., Chandra, A., Shenoy, P.: An observation-based approach towards self managing Web servers. In: International Workshop on Quality of Service, Miami Beach, FL (2002)

790

L.F. Orleans, G. Zimbrão, and P. Furtado

17. Schroeder, B., Harchol-Balter, M.: Achieving class-based QoS for transactional workloads. In: International Conference on Data Engineering, p. 153 (2006) 18. Serra, A., Gaïti, D., Barroso, G., Boudy, J.: Assuring QoS Differentiation and Load- alancing on Web Servers Clusters. In: IEEE Conference on Control Applications, pp. 885–890 (2005) 19. TPC-C Benchmark Homepage, http://www.tpc.org/tpcc/