Software aging: Difference between revisions

Content deleted Content added

Inline

Revision as of 23:03, 3 November 2015

Introduction

What is software aging?

"Programs, like people, get old. We can't prevent aging, but we can understand its causes, take steps to limits its effects, temporarily reverse some of the damage it has caused, and prepare for the day when the software is no longer viable."^[1]

In software engineering, software aging is the lifespan of software. As the software gets older it becomes less immune and will eventually stop functioning as it should and therefore, rebooting or reinstalling software can be seen as a short term fix. A proactive fault management method to deal with the software aging incident is software rejuvenation. This method can be classified as an environment diversity technique that usually is implemented through software rejuvenation agents (SRA).

What is software rejuvenation?

Several recent studies have established that most system outages are due to software faults. Given the ever increasing complexity of software and the well-developed techniques and analysis for hardware reliability, this trend is not likely to change in the near future. In this paper, we first classify software faults and discuss various techniques to deal with them in the testing/debugging phase and the operational phase of the software. We discuss the phenomenon of software aging and a preventive maintenance technique to deal with this problem called software rejuvenation. Stochastic models to evaluate the effectiveness of preventive maintenance in operational software systems and to determine optimal times to perform rejuvenation for different scenarios are described. We also present measurement-based methodologies to detect software aging and estimate its effect on various system resources. These models are intended to help develop software rejuvenation policies. An automated online measurement-based approach has been used in the software rejuvenation agent implemented in a major commercial server.^[2]

Memory leaks

Lock contention

Unreleased file handles

Memory/swap space bloat

References

R. Matias Jr. and P. J. Freitas Filho, "An experimental study on software aging and rejuvenation in web servers," Proceedings of the 30th Annual International Computer Software and Applications Conference (COMPSAC'06), Vol. 01, pp. 189 – 196, 2006.
M. Grottke, R. Matias Jr., and K. S. Trivedi, "The Fundamentals of Software Aging," Workshop of Software Aging and Rejuvenation (WoSAR/ISSRE), 2008.
R. Matias Jr, P. Barbetta, K. Trivedi, P. Freitas Filho "Accelerated Degradation Tests Applied to Software Aging Experiments," IEEE Transactions on Reliability 59(1): 102-114,2010.
M. Grottke, L. Li, K. Vaidyanathan, and K.S. Trivedi, "Analysis of software aging in a web server," IEEE Transactions on Reliability, vol. 55, no. 3, pp. 411–420, 2006.
M. Grottke, K. Trivedi, "Fighting Bugs: Remove, Retry, Replicate, and Rejuvenate," IEEE Computer 40(2): 107-109, 2007.
More papers on Proceedings of Workshop of Software Aging and Rejuvenation (WoSAR'08,'10, '11, '12, '13, '14) at IEEE Xplore.

This software article is a stub. You can help Wikipedia by expanding it.

^ Parnas, D.L. (1994-05-01). "Software aging". , 16th International Conference on Software Engineering, 1994. Proceedings. ICSE-16: 279–287. doi:10.1109/ICSE.1994.296790.
^ Trivedi, Kishor S.; Vaidyanathan, Kalyanaraman (2004-01-01). Reis, Ricardo (ed.). Software Rejuvenation - Modeling and Analysis. IFIP International Federation for Information Processing. Springer US. pp. 151–182. doi:10.1007/1-4020-8159-6_6. ISBN 978-1-4020-8158-3.

[1] Parnas, D.L. (1994-05-01). "Software aging". , 16th International Conference on Software Engineering, 1994. Proceedings. ICSE-16: 279–287. doi:10.1109/ICSE.1994.296790.

[2] Trivedi, Kishor S.; Vaidyanathan, Kalyanaraman (2004-01-01). Reis, Ricardo (ed.). Software Rejuvenation - Modeling and Analysis. IFIP International Federation for Information Processing. Springer US. pp. 151–182. doi:10.1007/1-4020-8159-6_6. ISBN 978-1-4020-8158-3.

[1]

[2]

@@ Line 4: / Line 4: @@
 "Programs, like people, get old. We can't prevent aging, but we can understand its causes, take steps to limits its effects, temporarily reverse some of the damage it has caused, and prepare for the day when the software is no longer viable."<ref>{{Cite journal|title = Software aging|url = http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=296790|journal = , 16th International Conference on Software Engineering, 1994. Proceedings. ICSE-16|date = 1994-05-01|pages = 279-287|doi = 10.1109/ICSE.1994.296790|first = D.L.|last = Parnas}}</ref>
-In [[software engineering]] software aging is the lifespan of [[software]]. As the software gets older it becomes less immune and will eventually stop functioning as it should and therefore, [[Reboot (computing)|rebooting]] or reinstalling software can be seen as a short term fix.
+In [[software engineering]], software aging is the lifespan of [[software]]. As the software gets older it becomes less immune and will eventually stop functioning as it should and therefore, [[Reboot (computing)|rebooting]] or reinstalling software can be seen as a short term fix. A proactive fault management method to deal with the software aging incident is [[software rejuvenation]]. This method can be classified as an environment diversity technique that usually is implemented through software rejuvenation agents (SRA).
 === What is software rejuvenation? ===
+Several recent studies have established that most system outages are due to software faults. Given the ever increasing complexity of software and the well-developed techniques and analysis for hardware reliability, this trend is not likely to change in the near future. In this paper, we first classify software faults and discuss various techniques to deal with them in the testing/debugging phase and the operational phase of the software. We discuss the phenomenon of software aging and a preventive maintenance technique to deal with this problem called software rejuvenation. Stochastic models to evaluate the effectiveness of preventive maintenance in operational software systems and to determine optimal times to perform rejuvenation for different scenarios are described. We also present measurement-based methodologies to detect software aging and estimate its effect on various system resources. These models are intended to help develop software rejuvenation policies. An automated online measurement-based approach has been used in the software rejuvenation agent implemented in a major commercial server.<ref>{{Cite book|title = Software Rejuvenation - Modeling and Analysis|url = http://link.springer.com/chapter/10.1007/1-4020-8159-6_6|publisher = Springer US|date = 2004-01-01|isbn = 978-1-4020-8158-3|pages = 151-182|series = IFIP International Federation for Information Processing|doi = 10.1007/1-4020-8159-6_6|language = en|first = Kishor S.|last = Trivedi|first2 = Kalyanaraman|last2 = Vaidyanathan|editor-first = Ricardo|editor-last = Reis}}</ref>
-In [[software engineering]], software aging refers to progressive performance degradation or a sudden [[Crash (computing)|hang/crash]] of a [[software]] system due to exhaustion of [[operating system]] resources, [[Fragmentation (computing)|fragmentation]], and/or accumulation of errors. A proactive fault management method to deal with the software aging phenomenon is [[software rejuvenation]]. This method can be classified as an environment diversity technique that usually is implemented through software rejuvenation agents (SRA). The simplest ways to emulate software rejuvenation are to [[reboot (computing)|reboot the system]] or find, close and restart the aging [[Application_software|application]].
 == Memory leaks ==
-[[Memory leak]]s are a potential cause or contributing factor in software aging, as they can exhaust available system [[computer memory|memory]].
-The program reads one number at a time and calculates its square value. This implementation uses a primitive “cache” for storing the results of the calculation. But since these results are never read from the cache, the code block represents a memory leak. If we let this program run and interact with users long enough, the “cached” results consume a lot of memory. It serves as a good sample of the aging – this program could be used for days before the end users are affected.<syntaxhighlight lang="java" line="1">
-public class Calc {
-  Map cache = new HashMap();
-  public int square(int i) {
-     int result = i * i;
-     cache.put(i, result);
-     return result;
-  }
-  public static void main(String[] args) throws Exception {
-     Calc calc = new Calc();
-     while (true)
-        System.out.println("Enter a number between 1 and 100");
-        int i = readUserInput(); //not shown
-        System.out.println("Answer " + calc.square(i));
-     }
-  }
-}
-</syntaxhighlight>
 == Lock contention ==
-You must all have been in the situation where the application behaves just fine for years and then after a small bump in load you start facing situations where the threads start waiting behind synchronized blocks and are either starved or completely locked out.
-The following sample serves as a textbook illustration to the case. The code will work just fine until you launch two threads which attempt to run transfer(a,b) and transfer(b,a) at the same time resulting in a deadlock. And again, you could be happily running the code for months or years before a situation like this escalates to locked threads.
 == Unreleased file handles ==