Failure data analysis of a LAN of Windows NT based computers

Kalyanakrishnam, M.; Kalbarczyk, Zbigniew; Iyer, R.K.

doi:10.1109/reldis.1999.805094

Cited by 108 publications

(63 citation statements)

References 16 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…In addition, we also assume that all failures that occur within the trace are caused by unique failures. Such assumptions are well supported by previous failure analysis [15,25,26] that also found that it is incredibly difficult to identify the root cause and the duration of a failure.…”

Section: B Failure Definitionsupporting

confidence: 58%

An Empirical Failure-Analysis of a Large-Scale Cloud Computing Environment

Garraghan

Townend

2014

2014 IEEE 15th International Symposium on High-Assurance Systems Engineering

View full text Add to dashboard Cite

Abstract-Cloud computing research is in great need of statistical parameters derived from the analysis of real-world systems. One aspect of this is the failure characteristics of Cloud environments composed of workloads and servers; currently, few metrics are available that quantify failure and repair times of workloads and servers at a large-scale. Workload metrics in particular are critical for characterizing and modeling accurate workload behavior, enabling more realistic workload simulation and failure scenarios of systems. This paper presents the analysis of failure data of a large-scale production Cloud environment (consisting of over 12,500 servers), and includes a study of failure and repair times and characteristics for both Cloud workloads and servers. Our results show that failure characteristics for workload and servers are highly variable and that production Cloud workloads can be accurately modeled by a Gamma distribution. Repair times range between 30 seconds to 4 days, and 25 minutes to 8 days, for workloads and servers respectively.

show abstract

Section: B Failure Definitionsupporting

confidence: 58%

An Empirical Failure-Analysis of a Large-Scale Cloud Computing Environment

Garraghan

Townend

2014

2014 IEEE 15th International Symposium on High-Assurance Systems Engineering

View full text Add to dashboard Cite

show abstract

“…Murphy and Gent [16] discuss system crashes caused by 'software failures', 'hardware failures', 'system management' and 'other reasons', without providing specific data relevant to the separate components building the systems. A similar discussion has been presented by Kalyanakrishnan et al [17], who discuss breakdowns in terms of 'hardware or firmware problems', 'connectivity problems', 'crucial application failures' and problems with a software component'.…”

Section: ) To Analyse the Constraint On The Repair Resources Caused mentioning

confidence: 60%

“…A number of studies on breakdowns in computer systems already exist ( [12,13,14,15,16,17]. A major drawback in many of these studies ( [14], [15], [16], [17]) is that the breakdowns are not attached to specific devices and components. For example, Plank and Elwasif [14] provide time to a breakdown and time to recovery histograms, but these are related to the systems as a whole, not to particular components building the investigated systems.…”

Section: ) To Analyse the Constraint On The Repair Resources Caused mentioning

confidence: 99%

Constraint on Repair Resources, Optimal Number of Repairers and Optimal Size of a Serviced System

Todinov¹

2015

ijacsa

View full text Add to dashboard Cite

Abstract-The focus of this paper is the analysis of the constraint on the repair resources caused by breakdowns of components in large systems. The study has been conducted by creating a very efficient discrete-event simulator, based on a minheap data structure, for determining the probability of constraint on the repair resources.In finding the right balance between the number of repairers and salary costs, an exact optimisation algorithm has been proposed for the first time. The algorithm determines the optimal number of repairers which guarantees that the probability of constraint on the repair resources will not exceed an acceptable tolerable level. In addition, an exact optimisation algorithm has been proposed for the first time, for determining the maximum size of the system that can be serviced by a specified number of repairers so that the probability of constraint on the repair resources remains below a specified tolerable level. Unlike heuristic optimisation algorithms, the proposed algorithms are exact and always guarantee optimal solutions.The presented results are of significant importance to operators of computer networks, production systems, transportation networks, water distribution systems, electrical distribution networks etc. They are a solid basis for management decisions regarding the optimal number of maintenance personnel needed to service the breakdowns in large systems. Increasing the number of repairers beyond the optimal level leads to high salary costs while reducing the number of repairers below the optimal number leads to a poor quality of service.

show abstract

“…Most of the published studies are not directly focused to database systems. Nevertheless, published studies clearly point out software faults and operator faults as the most frequent causes for computer failures [16][17][18][19][20][21]. Furthermore, the great complexity of database administration tasks and the need of tuning and administration in a daily basis, clearly explains why operator/administrator faults are prevalent in database systems.…”

Section: Operator Faults In Dbmsmentioning

confidence: 99%

Joint evaluation of recovery and performance of a COTS DBMS in the presence of operator faults

Vieira

Madeira

2004

Performance Evaluation

View full text Add to dashboard Cite

A major cause of failures in large database management systems (DBMS) is operator/administrator faults. Although most of the complex DBMS available today have comprehensive recovery mechanisms, the effectiveness of these mechanisms is difficult to characterize. On the other hand, the tuning of a large database is very complex and database administrators tend to concentrate on performance tuning and disregard the recovery mechanisms. Above all, database administrators seldom have feedback on how good a given configuration is concerning recovery. This paper proposes an experimental approach to characterize both the performance and the recoverability of DBMS. Our approach is presented through a concrete example of benchmarking the performance and recovery of an Oracle DBMS running the standard TPC-C benchmark, extended to include two new elements: a faultload based on operator faults and measures related to recoverability. A classification of operator/administrator faults in DBMS is proposed. A set of tools have been designed and built to reproduce operator faults in an Oracle 8i DBMS, using exactly the same means used in the field by the real database administrator. This experimental approach is generic (i.e., can be applied to any DBMS) and is fully automatic. The paper ends with the discussion of the results and the proposal of guidelines to help database administrators in finding the balance between performance and recovery tuning.

show abstract

Failure data analysis of a LAN of Windows NT based computers

Cited by 108 publications

References 16 publications

An Empirical Failure-Analysis of a Large-Scale Cloud Computing Environment

An Empirical Failure-Analysis of a Large-Scale Cloud Computing Environment

Constraint on Repair Resources, Optimal Number of Repairers and Optimal Size of a Serviced System

Joint evaluation of recovery and performance of a COTS DBMS in the presence of operator faults

Contact Info

Product

Resources

About