2017, Vol. 50文章信息
- 闫永权, 郭平
- YAN Yongquan, GUO Ping
- 软件老化与抗衰的研究综述
- Summary on software aging and rejuvenation
- 武汉大学学报(工学版), 2017, 50(4): 597-607
- Engineering Journal of Wuhan University, 2017, 50(4): 597-607
- http://dx.doi.org/10.14188/j.1671-8844.2017-04-019
-
文章历史
- 收稿日期: 2015-11-17
来自Aberdeen的一份报告指出[1]：对于从事电子商务的网站来说，网页载入每延迟1 s将会导致顾客对该网页的访问量下降11%，顾客满意度下降16%，同时商业损失会增加7%.即一家电子商务网站每天的利润是10万的话，那么一年的损失累积为250万.如果网站出现宕机问题，那么损失将会更加严重.
一些研究表明[2, 3]，软件系统的性能下降或者突然的宕机等现象是由软件老化现象引起的.软件老化现象指长期运行的软件系统中，出现的状态异常、性能下降、系统宕机、失效等现象.软件老化通常表现为：资源泄露，文件句柄和套接字未释放，进程、线程未结束，碎片问题，数值累积错误等.Bernstein等人[4]发现早在19世纪60年代军用系统中就已出现了软件老化现象.伴随着软件开发的规模增大和复杂性的不断增加，软件老化出现在通讯系统中[5]、Web服务器中[6]、云计算系统中[7]、数据库管理系统中[8]，更为严重的是，爱国者导弹防御系统中[9]由于舍入误差的不断累积，系统未有效拦截到敌方导弹，由此造成了28名人员的损失.由于传统的容错技术无法避免软件老化现象的出现，为了处理由于软件老化引起的一系列问题，Huang等人[2]提出软件抗衰：通过偶尔或者周期性的清除软件运行中的老化状态，使得软件运行环境恢复到初始的正常状态.
软件系统的抗衰可以通过抗衰操作的概率状态模型进行简单的说明.在图 1中，运行的软件系统初始时处于鲁棒状态，运行一段时间后将进入易于失效的状态(从鲁棒状态到易于失效状态的状态转移概率为r2).当系统处于易于失效状态时，如果执行抗衰操作，那么此时系统将处于抗衰状态(状态转移概率为r4)，并且在抗衰操作执行后，系统将恢复到初始的鲁棒状态(状态转移概率为r3)；如果不执行任何操作，系统将进入失效状态(状态转移概率为r5)，当系统处于失效状态时，将不能提供任何服务，需要对软件系统进行重新启动以使得系统恢复到初始的鲁棒状态(状态转移概率为r1).
|
| 图 1 抗衰操作的概率状态模型 Figure 1 State probability model of rejuvenation |
自Huang等人于20世纪90年代提出软件老化与软件抗衰的概念以来，越来越多的学者开始关注软件老化现象.经过20多年不懈的努力，软件老化与抗衰的知识体系已经初步建立，越来越多的工业界人士在意识到软件老化引起的问题的同时也开始参与到软件老化和抗衰方法的研究中来.
1 软件老化的成因长期运行的软件系统(由系统软件、支撑软件和应用软件等组成的集合)会出现逐步的性能下降(当运行的软件系统处于老化状态时，其表现为软件系统提供的服务速度变慢或者仅提供受限的服务)、甚至是突然的服务失效(软件系统提供的服务与其应当提供的服务不一致，如提供不正确的服务或者不提供服务)等现象，而这些现象被称为老化现象.
软件系统中老化的现象是由于软件系统本身存在的缺陷被激活，导致系统出现错误状态，当累积的错误状态传递到软件系统提供的服务接口处，被系统外的应用调用所引发的现象.
软件系统中的缺陷指计算机软件中存在的某种破坏系统正常运行能力的问题.Grottke等人[10, 11]按照缺陷发现的难度和缺陷是否可重现的原则将缺陷划分为两类：曼德尔缺陷(Mandelbug)和波尔缺陷(Bohrbug).曼德尔缺陷指那些很难在开发和测试阶段被发现的缺陷，并且由该类缺陷导致的软件系统性能下降和失效很难被重现.波尔缺陷则与曼德尔缺陷相反，此类缺陷容易通过形式审查、软件测试等方法被找到，并且该缺陷在相同的条件下可以被反复激活.这里将与软件老化相关的缺陷称为老化缺陷.与软件老化相关的缺陷通常是曼德尔缺陷.一般情况下软件老化缺陷处于休眠状态，只有当老化缺陷的激活条件满足时，该缺陷才会被激活，此时将导致系统的状态由正常状态转变为老化状态.老化缺陷的激活依赖于软件系统使用的方式和包含该缺陷的模块被访问的频率.老化缺陷的激活条件可以分为内部老化条件和外部老化条件.内部老化条件：激发老化缺陷的内部条件，例如一个软件系统中内部的函数调用老化缺陷所在的代码，这种调用会激活此老化缺陷.外部老化条件：软件系统的外部环境条件，例如软件系统外的用户或其他外部系统通过显式调用与老化相关的服务接口，将导致老化缺陷被激活.
错误状态是软件系统的一种内部状态，与老化相关的错误状态称为老化错误状态.当老化错误状态出现时，此时系统尚能提供一定质量的服务，只有当老化错误状态累积到一定程度时，并且外部应用调用带有错误状态的服务接口时，才会导致系统失效等问题出现.图 2给出了软件老化失效链.
|
| 图 2 软件老化失效链 Figure 2 Failure chain of software aging |
在图 2中，当老化缺陷被激活后，老化错误状态将在软件系统内部积累，而通常这种累计的错误状态并不会导致系统突然失效，除非这种状态传递到软件系统所提供的服务接口处，并被调用.也就是说老化缺陷的激活和失效之间存在着一段较长的延时，而这种延时导致老化问题存在一定的隐蔽性，也对老化问题的检测带来一定的困难.
2 软件老化及抗衰的方法当软件系统出现老化问题时，可以通过抗衰使得软件系统恢复到初始的正常状态.软件老化和抗衰的方法分为两类：基于时间的抗衰方法和基于检测的抗衰方法.
2.1 基于时间的抗衰方法基于时间的抗衰方法首先假设系统中已经存在着软件老化问题，在此假设条件下，假定系统的运行状态、软件失效的分布、修复时间的分布等，然后使用选定的模型最大化系统可用时间或最小化抗衰代价，在执行抗衰时，按照确定的时间间隔执行抗衰操作.
基于时间的抗衰方法按照使用模型的不同还可细分为以下几种：
1) Markov模型及其相应的扩展模型
Huang等人[2]使用一个4状态(正常状态、老化状态、抗衰状态、失效状态)的连续时间Markov模型对软件老化过程进行建模，最大化系统可用时间.在此后多年中许多学者使用Markov和半Markov模型对软件老化问题进行了建模.如Garg等人[13]使用了非齐次连续时间Markov模型(每一个状态的停等时间是非指数分布的)对故障、性能下降时间、瞬时负载、累积平均负载等进行了建模.Okamura等人[14]首先使用连续时间Markov链模型表示服务器的性能下降，接着使用Markov模型调制的复合泊松过程表示服务器的响应时间分布.Xie等人[15]除了在系统层引入抗衰还在服务层引入抗衰，并使用半Markov模型(一个状态到另外一个状态的转移概率不仅与当前的状态有关，还与从一个状态到另外一个状态所花费的时间有关)对老化问题进行建模.Vaidyanathan等人[16]使用从Unix操作系统中收集的负载和系统资源数据构造了一个半Markov模型，并使用该模型计算每种资源的耗尽时间，之后将输出结果作为输入用于计算可用时间.尽管大部分研究集中于经典的Markov和半Markov模型，但一些扩展的Markov模型也被用来研究软件老化过程，如Okamura和Dohi[17]使用部分可观察马尔可夫决策过程(POMDP，运行的软件系统的状态信息只有部分可知)最大化系统可用时间.Markov模型及其扩展模型还被应用于以下方面：集群系统中老化的建模[18]；虚拟机及虚拟机监视器的老化问题[19, 20]；描述更加复杂的失效，使用多种失效对系统总的逐步减少的服务率进行建模[21, 22].
2) Petri网
Petri网模型是对离散并行系统的数学表示，适用于描述异步的、并发的计算机系统模型.Petri网模型能够形象描述系统的并行性、分布性、不确定性、资源竞争性等，在早期的抗衰中，通常采用此模型或者随机Petri网(在Petri网的基础上引入了时间参数和随机概念，假定系统在某一状态的驻留时间是一个连续的随机变量)描述抗衰策略.尽管随机Petri网可容易表示系统变化后的状态，但也存在不容易表示系统中参数值变化的问题，同时在实践中模型中假定的状态变迁的时间往往并不符合指数分布，因此后续又出现了随机Petri网模型、确定与随机Petri网、广义随机Petri网、马尔科夫再生随机Petri网等模型.Wang等人[23]使用确定和随机Petri网(其随机过程为一个Markov再生过程)对可变负载下的集群系统的老化问题进行了建模，并且在抗衰策略方面提出了3类抗衰策略：标准抗衰、延时抗衰、混合抗衰.Salfner和Wolter[24]使用一个扩展的随机Perti网模型评估3个基于时间的抗衰策略，并且发现当资源使用率低时所有的3个抗衰策略的执行效果都很好，但当资源使用率很高时，任何一个抗衰策略的执行效果都不好.Andrade等人[25]为了便于系统管理员执行抗衰操作提出使用SysML半形式化语言描述系统的配置和维护操作，并对随机补偿网抗衰操作与另外两类抗衰操作进行了比较.随着软件系统规模的不断增大以及复杂性的提高，Petri网表示的状态空间会随着系统规模的增大呈现指数型的增长，出现状态空间爆炸问题，这导致了模型难以理解，求解也愈加困难.
3) 其他建模方法
Eto等人[26]使用强化学习方法(不需要对系统失效或者性能下降有完整的知识)计算最佳抗衰时机.
基于时间的方法往往对系统的状态、负载等进行简单的假设，然而这类简单的假设在一个真实的应用系统中往往很难得到满足，同时此类模型在对所提出的模型进行验证时，往往采用经验分析或者采用模拟数据验证提出模型的有效性，而非使用现实系统中收集的数据进行验证.按照指定的时间间隔执行抗衰对于现实系统，尤其对于实时系统来说并不合适，间隔过小提前执行抗衰，间隔过大失效出现时未能及时执行抗衰.
2.2 基于检测的方法与基于时间方法中使用的数据不同的是，基于检测的方法使用的数据往往是真实运行系统中收集的数据(通常是在受控的环境下收集的数据).基于检测的方法首先通过负载产生工具产生负载数据，然后使用数据采集工具收集软件应用系统中的变量参数，也被称为老化参数，之后使用选定的算法对软件老化过程进行建模，预测软件老化失效的出现.基于检测的方法可以分为3类：
1) 时间序列方法
时间序列指将随机事件的各个数值在不同的时间点上，按照时间的先后顺序进行排列而组成的序列.Garg等人[27]使用基于SNMP协议开发的工具收集9个Unix工作站的系统参数.在整个数据收集期间，发现33%的失效是由于资源耗尽引起的.趋势测试方法(Mann-Kendall，Seasonal Kendall tests)常常被用来验证软件中是否存在老化现象：拒绝或者接受数据中是否没有趋势的假设.如果数据序列中没有趋势存在(上升或者下降)，则表明不存在老化现象，否则存在老化现象.Machida等[28]通过一系列的实验指出Mann-Kendall方法在软件老化现象的检测中很容易产生误报问题，使用Mann-Kendall方法用于检测软件老化问题可能并不合适或者说需要多次的实验测试才能够确定老化问题的存在.李磊等人[29]和Grottke等人[30]首先在受控的环境中(负载按照指定的分布产生)收集运行软件系统的系统资源使用参数，然后对相关参数进行建模并预测，最后使用预测值计算资源耗尽时间.Araujo等人[31]使用4种时间序列模型(线性模型，二次式模型，指数增长模型，皮尔生长曲线模型)，预测一个云计算平台中的内存消耗.Hoffmann等人[32]提出了一种对于资源消耗预测的最佳实践指导方法，使用了多变量非线性模型预测资源消耗，在实验中作者指出多变量非线性模型预测效果要好于多变量线性模型.时间序列算法还被应用于Linux内核代码[33]和Java虚拟机[34]中的老化问题分析中.
2) 机器学习方法
Cassidy等人[35]采用模式识别方法分析一个大型在线事物处理系统中共享内存池锁竞争引起的软件老化问题，通过分析系统实际参数值和预测值之间的偏差，发现通过检测偏差，可以提前2 h发现老化状态.Alonso等人[36]使用回归树模型(每一个节点都是一个系统参数，每一个节点都可以表示为下层节点的线性组合)对一个3层J2EE系统进行建模，并使用模型的输出结果计算系统资源耗尽时间.
3) 基于固定门限值的方法
与前两种方法不同的是，基于固定门限值的方法首先定义老化参数的临界值，当这些被观测的老化参数的值超过预定义的临界值时，将会执行抗衰操作以消除老化引起的问题.Matias等人[37]将虚拟内存作为软件老化标示，通过指定Apache服务器的虚拟内存临界值，当监视的虚拟内存值超过指定的临界值时执行抗衰操作，作者在实验中使用3个可控的负载参数：页大小，页类型(动态或静态)，请求率控制Apache服务器的内存消耗速度.Silva等人[38]将响应时间作为老化标示，计算虚拟机上的平均响应时间，在此基础上给出一个临界值，一旦超过临界值则在虚拟机上执行抗衰.Araujo等人[31]对一个云计算平台中的老化问题执行抗衰：首先使用时间序列模型预测资源消耗，然后针对资源消耗定义多个临界值，当预测值超过临界值时执行抗衰操作.基于固定门限值的方法存在一个问题，即如何找到一个合适的临界值，临界值过大可能导致系统长久处于老化状态，临界值过小会导致系统在正常状态下过早地执行抗衰操作.
基于检测的方法使用受控实验中收集的数据对软件老化进行分析，其优势在于软件老化的分析是针对特定的系统，能够较为准确地确定软件老化现象的出现.然而，由于基于检测的方法收集的数据来自于特定的软件系统，因此泛化能力较差，例如资源消耗参数在一些文章中[27, 39]出现周期性，但不能就此断言此消耗参数存在着周期性.目前基于检测的方法往往使用时间序列方法预测相关参数，然后使用诸如资源耗尽时间估计老化时间，但是由于系统的老化[13, 16, 37, 40-42]与负载类型和大小等有关，因此很难准确地估计资源耗尽时间.
基于时间的方法使用的数据来自于模拟数据，但是也有一小部分使用真实的数据，如Zhao等人[43]采用Apache服务器的数据验证其提出的反向错误传播网络的有效性.同样大部分的基于检测的方法使用的数据来自于受控(人为控制负载大小和类型)实验中通过数据采集工具(如Monit[44], Ganglia[45], Munin[46]，或者Nagios[47])采集到的数据；但是也有一小部分采用模拟数据，如Kim等人[48]使用模拟数据评估当网络遭遇拒绝访问攻击时，一个感知器网络中感知器的生存性问题.
从以上的分析可以看到，软件老化和抗衰目前的研究重点在抗衰操作的时机选择上，而非抗衰操作的具体执行上，即抗衰调度.
3 识别软件老化的参数目前对于软件老化的识别主要通过对遭受老化影响的软件系统中的相关参数进行分析加以识别.软件老化参数是那些可以表明运行时的软件系统是否处于老化状态的单个参数或者多个参数.
老化参数按照表现形式可以分为资源消耗参数和性能参数.
3.1 资源消耗参数资源消耗参数主要分为内存消耗参数和其他资源消耗参数.
1) 内存消耗参数
Garg等人[27]指出在系统资源中可用内存的耗尽会导致软件老化问题的出现.此后，许多针对软件老化和抗衰的研究使用可用内存参数[29, 49]作为时间序列、统计模型等的输入，用于构造老化和抗衰模型.
2) 其他资源消耗参数
除了内存参数可以作为软件老化资源消耗参数，资源消耗参数还包含其他一些参数：与文件相关的资源参数，如流描述符和文件句柄[27, 50-51]；与网络相关的资源，如套接字描述符[50]；与并发性相关的资源，如锁、线程、进程等[27, 51]；与特定应用相关的资源，如数据库管理系统共享池锁[35]；Web服务器中的资源消耗参数，如堆内存.
3.2 性能参数造成软件系统性能下降的原因是系统运行时与服务相关的资源被耗尽，例如由于内存管理机制的缺陷，随着时间的增加系统所需的物理内存越来越多(与负载无关)，这种持续增加的物理内存需求最终会导致物理内存的耗尽，同时还会伴随着系统性能下降问题[52, 53].对于Web应用和服务[29, 37, 54]，基于Corba的应用[52]来说，响应时间和吞吐率被作为老化性能参数，用于判断老化问题的出现.
除了以上参数可以作为老化参数外，不正确的API调用等也被作为软件老化的标志.如Zhang等人[51]通过监视API调用，发现Java I/O中存在软件老化现象.Garg等人[27]不仅收集Unix工作站中的交换空间参数，还收集操作系统内核、硬盘、文件系统、网络等参数信息，并且发现老化现象与进程表大小和文件表大小有关.
软件老化的表现除了体现在系统的性能下降和意外的停止服务外，累积的数值错误[3]也是软件老化现象的一种表现.此外，有一类应用系统[55]的老化现象是与老化缺陷无关的，如在Oracle数据库管理系统中可以通过表空间的碎片值来判断系统是否处于老化状态.
从相关的文献来看，大部分的研究都将资源消耗参数和性能参数作为老化参数确定运行软件系统是否存在老化问题，其中资源消耗参数易于获取，但并不能直接表明系统所处的状态；性能参数受多种因素的影响，在获取时往往存在较大的误差，因此难以准确判断系统的当前状态，与此同时，在对老化参数的选择中缺少一种定量的方法去选择老化参数.累积的数值错误不仅与系统的设计缺陷有关，还与浮点运算中的内存分配算法有关，目前还没有与之对应的老化参数用于检测此类软件老化问题.
4 遭受老化影响的系统遭受软件老化影响的系统按照系统类型可以分为3类：安全性系统，非安全性系统，未指定系统.
安全性系统指系统在运行过程中，如果出现性能下降或者非预期的宕机会导致重大经济损失，甚至是生命的损失.安全性系统包括军用系统、航空航天系统等.非安全系统指系统运行过程中出现性能下降不会造成重大经济损失及生命的损失，这些系统包括一些商业系统，例如Web服务、数据库服务等.未指定的系统指那些使用模拟数据或者通过数值举例来证明所使用老化和抗衰方法有效的系统.
表 1给出了3类系统在相关研究的文献所占的大致比例.
从该表中可以看到针对安全性系统的研究只占到很小一部分，而非安全性系统占据一半以上.这是因为安全性系统往往经过了严格的设计开发与测试.尽管安全性系统经过了严格的设计开发和测试，但仍然存在着软件老化问题.
1) 安全性系统
由于安全性系统经过了严格的开发与测试，因此此类老化问题涉及的相关研究文献较少.Grottke等人[3]发现在爱国者导弹系统中，存在着由舍入误差引起的老化失效，而解决该问题的办法只能通过每隔几个小时重新启动系统以清除由累积舍入误差引发的老化.Tai等人[56]于1999年首次对美国航空航天局中X2000计算系统(航空航天系统)中的老化问题进行了描述，Grottke等人[57]对18个JPL/NASA空间任务中的缺陷进行了分析，并且研究了缺陷类型是如何随着时间演化的.
2) 非安全性系统
非安全系统中，最早的关于通信系统的软件老化问题来自于美国电话电报公司.Balakrishnan等人[58]于1997年分析了通信收费应用系统和交换机软件中的老化问题.Liu等人[59, 60]针对一个电缆调制解调器终端系统提出了主动抗衰维护技术.Okamura等人[61]假设服务请求的到来服从Markov调制泊松过程，对一个通信系统的可信性能进行了评估.
操作系统的软件老化研究最早来自于对Unix操作系统中出现的老化问题的研究，在之后的多年内陆续出现了对Linux系统[33, 49, 62-63]、Solaris系统[64]、Windows NT系统[65]和Android系统[66]的老化问题研究.对于DNS服务器的老化问题的研究主要集中于通过抗衰阻止与安全有关的失效[67]和检测由安全缺陷引起的老化[68]问题.
针对Web服务系统的研究集中于Apache Web服务器，这类研究主要采用基于检测的方法研究Web服务的老化问题.这些工作[28-29, 37, 42]首先从Apache服务器上收集资源使用参数(如内存消耗、交换空间、缓存使用等)和性能参数(如响应时间)，之后使用收集的数据集训练模型，然后使用训练后的模型预测资源消耗.
云计算平台的老化问题是软件老化问题的一个新兴的研究方向.最初的云计算平台的软件老化问题集中于虚拟机和虚拟机监视器的重启和抗衰，这部分研究既有基于时间的方法研究[69]，也有基于检测的方法研究[20, 31].
3) 未指定系统
在表 1中，非指定系统的研究占到了39%，这类研究并没有使用真实系统中采集到的数据，而是采用模拟数据或者数值举例等方法证明所提出方法的有效性.
5 软件抗衰粒度软件抗衰粒度指从何种层次上对软件执行抗衰，以及执行抗衰所影响的范围.按照应用系统的特点抗衰粒度分为3类：一般应用的抗衰；针对特定应用的抗衰(利用特定应用的特点执行抗衰)；未指定的抗衰(抗衰未明确应用于某个或某类应用系统).
5.1 一般应用的抗衰该类抗衰又可细分为：操作系统重新启动，应用重新启动，虚拟机和虚拟监视器重新启动，集群抗衰等.
1) 操作系统重新启动
通过重启操作系统执行抗衰(硬件重新启动，引导加载程序，加载内核，重新加载所有用户应用)，操作系统重启后其上的所有应用将释放自身所占的资源.通过无效化Linux和Solaris操作系统的主存[70, 71]并且从入口点重新启动操作系统，可以减少硬件重启带来的额外时间损耗.随着操作系统的重新启动，重启操作系统对于其上的应用来说会带来性能损失问题：缓存的内容被清空了，而缓存会加快其上应用对于文件的访问速度.为了解决这一性能损失问题，Kourai[72]提出一种称为缓存热启动的技术：首先保存缓存的内容，当操作系统重新启动后加载缓存的内容.然而这种技术需要处理文件缓存与硬盘上内容不一致问题(文件内容主存上修改了，但在重启之前未写入物理硬盘).Bovenzi等[63]针对Linux操作系统的抗衰操作引起的性能损失问题，提出了一种快速重启(基于阶段和Kexec的重启)的操作系统抗衰.
2) 应用重新启动
通过重新启动整个应用执行抗衰操作[2]，执行完此类抗衰后，应用的状态回复到初始正常状态.应用重新启动的抗衰机制会使得整个应用进入到最开始的状态，这种抗衰操作不会影响到该软件所处的环境，即其下的操作系统和同级的应用.
3) 虚拟机监视器和虚拟器的重新启动
虚拟机监视器和虚拟机的重新启动就是指抗衰在虚拟层中进行，通过重启虚拟机监视器或者虚拟机达到软件抗衰的目的.为了解决操作系统重新启动引起的应用性能损失问题，Kourai[20, 22]提出使用虚拟机技术使得操作系统运行在一个虚拟机中，在虚拟机监视器里保存操作系统重启之前的文件缓存状态，当虚拟机中的操作系统重启后，重新加载虚拟机监视器里保存的缓存内容.虚拟机重启又可分为冷的虚拟机抗衰和热的虚拟机抗衰.在冷的虚拟机抗衰中，当虚拟机监视器执行抗衰操作时，其上的虚拟机也被重新启动了.在热虚拟机重启中，每一个虚拟机(虚拟机及其内的操作系统、应用系统)被存储到了永久的介质中，当虚拟机监视器被重新启动后，虚拟机被重新加载，这样就减少了重新启动虚拟机和其上服务的停机时间，这类抗衰可以通过内存挂起的机制将虚拟机的内存映像保存到硬盘上.Machida等人[73]为了减少虚拟机重启带来的停机等待问题，提出当虚拟机监视器执行抗衰时，将虚拟机迁移到另外一个主机上，这样当虚拟机监视器执行抗衰时，此虚拟机仍然可以提供服务.但是这种方法受限于其他主机的性能，如果其他主机接收虚拟机映像速度慢那么当该虚拟机停止服务后，其他主机就不能立刻提供服务.
4) 集群抗衰
通过对集群系统(由一些提供相同服务的软硬件系统组成)中一个遭受老化影响的系统执行抗衰操作，在抗衰操作执行期间，其他备用系统处于运行状态，负载也被重定向到这些系统上[18, 74, 75]以继续提供服务.Park等人[76]使用双机热备技术执行抗衰：当其中一台服务器执行抗衰时，负载转向到另外的服务器上.Silva等人[38, 77]提出了基于虚拟技术的集群抗衰框架，该框架包含一个负载均衡器，双机热备(主备方式).负载均衡器用于将负载定向到服务器并且监视主服务器中的老化现象(当某些老化参数低于一个指定值时，表明老化问题出现)，当主服务器执行抗衰时，新的请求被发送到备用服务器上，同时备用服务器将会加载主服务器中被保存的会话数据等信息.
5.2 针对特定应用的抗衰与一般应用抗衰不同的是，针对特定应用的抗衰，利用软件应用系统本身的特性(软件的架构、特定的资源类型等)，减小执行抗衰的代价.该类型的抗衰包括：
1) 基于组件系统的抗衰
对于组件的抗衰来说，组件之间的重启相关度(一个组件的重启可能导致其他组件的状态出现错误)以及重启树的构建是两大关键问题.与基于整个应用的抗衰相比，基于组件的抗衰只是重启应用的一部分.例如，当Apache服务器中的子进程服务的请求达到一定的数目或者用户结束了该子进程，此时主进程将会产生一个新的子进程用来接受用户请求[29, 78, 79]，而非重新启动整个Apache服务器.Candea等人[80, 81]提出了软件的微启动概念(快速重启一个部件而不影响系统中的其他部分)：重新启动个体Java Bean，并将这种方法成功地应用于一个J2EE应用.微启动定义为：建立一颗重启树，此树中的各个节点是可以独立重启的进程或者应用，当需要执行重启操作时，从重启树的底层节点开始重启，如果系统不能恢复到初始的正常状态，则重启重启树的上一层节点.微启动要求软件在开发时要遵循组件之间松耦合原则.如果组件之间不存在松耦合的关系，需要重新开发系统才能进行微启动，然而现有的软件系统大部分都不符合松耦合的原则.
2) 嵌入式系统的抗衰
Sundaram等人[82]提出在多任务嵌入式系统中使用微抗衰的方法处理老化问题.此方法使用了一种称为共享补充内存的技术：当应用系统使用的堆内存或栈内存超过了预先给定的门限值，新增的内存将来自于共享补充内存.当共享补充内存的使用率超过预先给定门限值时，将在共享补充内存上执行抗衰操作，通过此方法可以增加嵌入式系统的可靠性，延长可用时间.
3) 有状态的分布式系统的抗衰
传统的基于分布式系统的抗衰通常是一种无状态的抗衰：当一个节点执行抗衰操作时，负载将转到其他节点上执行而不考虑之前的会话状态.但这种抗衰策略对于有状态的分布式系统应用来说并不适用，因为这样做可能会导致节点间状态出现不一致.Tai等人[83]提出使用一个并发的控制协议去保证节点之间的最终一致性而非瞬时一致性.当一个节点执行抗衰时，负载将会被保存在缓存中，并且通过一个专用的节点将此负载在所有的分布式节点中传播，这样最终所有节点的状态将会保持一致状态.
4) 数据库管理系统的抗衰
由于共享池锁的竞争[35, 84](同步机制导致访问共享内存的时间越来越长)，数据库管理系统中也出现了软件老化问题.这种老化问题是由于共享内存的耗尽或者过多的碎片造成的，通过刷新共享内存区域的方式可以减轻老化问题带来的影响.Bobbio等人[85]发现随着重做日志文件的不断增长，数据库管理系统所占的硬盘资源会耗尽，其提出的抗衰办法很简单：将重做日志文件转移到另外一块硬盘上.
5) 编程语言上的抗衰
一些编程语言，如C#和Java通过垃圾回收机制执行抗衰以避免内存泄露问题.但是垃圾回收机制并不能完全避免内存的泄露问题，Bond和McKinley[86]提出使用Melt方法，将检测到的不可访问的对象转移到硬盘上同时释放这些对象占有的内存，但这种方法只是延长了系统的可用时间，并不能从根本上解决老化问题.Gama和Donsez[87]通过使用面向方面编程技术跟踪那些在OSGi Web应用中未使用的对象.Jeong等人[88]提出使用Kernel-AssistedLeak toleration (KAL)模式去回收C/C++程序中泄露的内存：KAL获取正在运行应用的内存情况，分析获得的内存快照，确定内存泄露的位置，然后调用标准内存管理程序回收内存.
5.3 未指定的抗衰这类抗衰并未将提出的抗衰策略应用于任何一种现实系统上，所执行的抗衰往往仅仅是从理论上讨论可行性，大部分集中于基于时间的老化和抗衰研究上[2, 85].
一般应用的抗衰并不使用应用本身的特性，而是依赖于重启操作系统、应用系统等，重启后系统恢复到初始的正常状态.特定应用的抗衰中有相当一部分的研究是对Apache Web服务器的抗衰进行研究，而对其他的Web服务器的抗衰研究则很少.由于基于状态分布式系统应用的抗衰需要保存相应应用的状态同时避免与老化相关的错误状态被保存进去，因此较无状态的分布式系统应用的抗衰更为复杂，此方面的研究相对于无状态的分布式系统应用的抗衰工作较少，这类有状态分布式系统的抗衰在将来的研究工作中将是一个值得研究的方向.未指定的抗衰主要集中在基于时间的老化研究中，其往往采用模拟数据或者数值举例来验证其提出方法的有效性.需要说明的是，无论是一般应用的抗衰还是特定应用的抗衰，这些抗衰研究的重点在于找到一个合适的抗衰时机而非设计一个抗衰操作的执行步骤.
6 结束语软件老化和抗衰是随着计算机与网络技术发展衍生出的一个新的研究方向，涉及性能检测、故障诊断、可靠性、可用性等多方面技术.目前学术界普遍认为各类资源的消耗是造成老化问题出现的主要原因.尽管通过对资源占用等方面的检测可以评估一个系统的当前运行情况，然而软件老化与抗衰还有以下需要解决的问题.
1) 系统中老化参数的确定
对于软件老化和抗衰来说，如何确定老化参数是一个需要解决的问题.目前的研究往往使用资源消耗参数和性能参数作为老化的参数，对于老化问题来说，老化往往是在一种或多种资源消耗共同影响下出现的.对于软件应用来说，出现老化后，各种资源消耗的程度是不同的，甚至可能会出现即使每类资源的消耗都不严重，仍然会出现性能下降的现象，因此，如何在不同的运行环境下选择一个合适的老化参数子集是一个需要考虑的问题.
2) 如何提高老化参数的预测精度
在确定老化参数后，为了能够提前预知系统的状态，下一步需要对老化参数进行预测，而目前针对系统中的资源消耗参数(老化参数的一种)往往采用单一的线性或者非线性的方法，因此如何提高资源消耗的预测精度也是一个值得研究的问题.
3) 老化状态的确定
由于软件系统遭受老化的影响往往是多方面因素共同作用的结果，因此很难通过单一的因素判断系统的状态，如何通过多个老化参数合理地判断软件状态也是一个需要考虑的问题.
4) 抗衰策略的选取问题
目前抗衰策略大致上可以分为基于时间的和基于检测的抗衰策略.其中，基于时间的策略往往采用Markov等模型对老化状态进行建模，在抗衰时按照指定的时间间隔执行抗衰，抗衰策略较为保守；基于检测的抗衰策略使用采集到的资源参数对老化过程进行建模，使用资源耗尽时间或者响应时间等作为系统是否出现老化的依据，据此执行抗衰，因此在抗衰上较基于时间的更为准确，但会导致较大的计算成本.因此在某些情况下，如何综合两种抗衰策略是一个值得考虑的问题.
5) 新出现软件系统的老化问题
随着新技术的不断出现，新的软件系统中也出现了老化问题，如云计算平台、Android系统，对于此类系统如何找到一个合适的老化参数及选择一个合适的抗衰策略也是需要考虑的问题.同时，如何对那些舍入误差造成的老化进行检测也需要考虑.
6) 抗衰粒度的选择问题
可以按照不同的粒度对软件系统执行抗衰，但如果粒度大则受抗衰影响的应用多，如果抗衰粒度小那么现有的系统必须重新改造，成本过大.因此，如何针对不同的应用特点选择一个合适的抗衰粒度也是值得考虑的问题.
7) 抗衰频率选择的问题
在以往的研究中，收集的抗衰数据往往是基于受控环境下的监测数据，甚至是一些模拟数据，而非真实运行环境中的数据，因此，使用此类数据不能反映系统的真实运行情况，会造成抗衰过于频繁或者抗衰不足问题的出现.如果抗衰过于频繁，系统经常进行抗衰操作，这样会降低使用系统的用户体验感.如果抗衰不足，则不能保证系统状态处于正常状态，甚至会发生服务失效问题，同样也会造成用户体验感下降.
| [1] | Cheat Sheet: Everything you wanted to know about web performance but were afraid to ask[EB/OL]. http://www.webperformancetoday.com/2010/06/15/everything-you-wanted-to-know-about-web-performance/. |
| [2] | Huang Y, Kintala C, Kolettis N, et al. Software rejuvenation: Analysis, module and applications[C]// Twenty-Fifth International Symposium on IEEE Fault-Tolerant Computing, IEEE, 1995: 381-390. https://www.computer.org/csdl/proceedings/ftcs/1995/7079/00/70790381-abs.html |
| [3] | Grottke M, Matias R, Trivedi K S. The fundamentals of software aging[C]// IEEE International Conference on Software Reliability Engineering Workshops, IEEE, 2008: 1-6. http://ieeexplore.ieee.org/document/5355512/ |
| [4] | Bernstein L, Kintala C M R. Software rejuvenation[J]. CrossTalk, 2004, 17(8): 23–26. |
| [5] | Avritzer A, Weyuker E. Monitoring smoothly degrading systems for increased dependability[J]. Empirical Software Eng. J., 1997, 2(1): 59–77. |
| [6] | Jia Y F, Su J Y, Cai K Y. A feedback control approach for software rejuvenation in a web server[C]// IEEE International Conference on Software Reliability Engineering Workshops, IEEE, 2009: 1-6. http://ieeexplore.ieee.org/document/5355514/ |
| [7] | Dean D J, Nguyen H, Gu X. Ubl: unsupervised behavior learning for predicting performance anomalies in virtualized cloud systems[C]// Proceedings of the 9th International Conference on Autonomic Computing, ACM, 2012: 191-200. http://dl.acm.org/citation.cfm?id=2371572 |
| [8] | Bovenzi A, Cotroneo D, Pietrantuono R, et al. On the aging effects due to concurrency bugs: A case study on mysql[C]// IEEE 23rd International Symposium on Software Reliability, IEEE, 2012: 211-220. https://www.researchgate.net/publication/233794388_On_the_Aging_Effects_due_to_Concurrency_Bugs_a_Case_Study_on_MySQL?_sg=5l3-ggdR4lZW9uDmiqSWaWSCVKf8c0y1EB_rQoS4HnDPvmFeC5PaSnWQ-DebhRw9xD7-jWsJL9aDJtBaGo2Hwg |
| [9] | Marshall E. Fatal error: how patriot overlooked a scud[J]. Science, 1992, 255(5050): 1347–1347. DOI:10.1126/science.255.5050.1347 |
| [10] | Grottke M, Trivedi K S. Software faults, software aging and software rejuvenation[J]. Journal of the Reliability Association of Japan, 2005, 27(7): 425–438. |
| [11] | Grottke M, Trivedi K S. Fighting bugs: remove, retry, replicate and rejuvenate[J]. IEEE Computer, 2007, 40(2): 107–109. DOI:10.1109/MC.2007.55 |
| [12] | Bernstein L. Innovative technologies for preventing network outages[J]. AT&T Technical Journal, 1993, 72(4): 4–10. |
| [13] | Garg S, Puliafito A, Telek M, et al. Analysis of preventive maintenance in transactions based software systems[J]. IEEE Transactions on Computers, 1998, 47(1): 96–107. DOI:10.1109/12.656092 |
| [14] | Okamura H, Luo C, Dohi T. Estimating response time distribution of server application in software aging phenomenon[C]// 2013 IEEE International Symposium on Software Reliability Engineering Workshops, IEEE, 2013: 281-284. http://ieeexplore.ieee.org/document/6688907/ |
| [15] | Xie W, Hong Y, Trivedi K. Analysis of a two-level software rejuvenation policy[J]. Reliability Engineering & System Safety, 2005, 87(1): 13–22. |
| [16] | Vaidyanathan K, Trivedi K S. A comprehensive model for software rejuvenation[J]. IEEE Transactions on Dependable and Secure Computing, 2005, 2(2): 124–137. DOI:10.1109/TDSC.2005.15 |
| [17] | Okamura H, Dohi T. A pomdp formulation of multistep failure model with software rejuvenation[C]// 2011 IEEE Third International Workshop on Software Aging and Rejuvenation, IEEE, 2011: 14-19. http://dl.acm.org/citation.cfm?id=2121922.2122240 |
| [18] | Xie W, Hong Y, Trivedi K S. Software rejuvenation policies for cluster systems under varying workload[C]// 10th IEEE Pacific Rim International Symposium on Dependable Computing, IEEE, 2004: 122-129. http://dl.acm.org/citation.cfm?id=978729 |
| [19] | Hla Myint M T, Thein T. Availability improvement in virtualized multiple servers with software rejuvenation and virtualization[C]// 2010 Fourth International Conference on Secure Software Integration and Reliability Improvement, IEEE, 2010: 156-162. https://www.computer.org/csdl/proceedings/ssiri/2010/4086/00/4086a156-abs.html |
| [20] | Kourai K, Chiba S. A fast rejuvenation technique for server consolidation with virtual machines[C]// 37th Annual IEEE/IFIP International Conference on Dependable Systems and Networks, IEEE, 2007: 245-255. http://dl.acm.org/citation.cfm?id=1253072 |
| [21] | Du X, Qi Y, Hou D, et al. Modeling and performance analysis of software rejuvenation policies for multiple degradation systems[C]// 33rd Annual IEEE International Computer Software and Applications Conference, IEEE, 2009: 240-245. http://dx.doi.org/10.1109/COMPSAC.2009.39 |
| [22] | Kourai K, Chiba S. Fast software rejuvenation of virtual machine monitors[J]. IEEE Transactions on Dependable and Secure Computing, 2011, 8(6): 839–851. DOI:10.1109/TDSC.2010.20 |
| [23] | Wang D, Xie W, Trivedi K S. Performability analysis of clustered systems with rejuvenation under varying workload[J]. Performance Evaluation, 2007, 64(3): 247–265. DOI:10.1016/j.peva.2006.04.002 |
| [24] | Salfner F, Wolter K. Analysis of service availability for time-triggered rejuvenation policies[J]. Journal of Systems and Software, 2010, 83(9): 1579–1590. DOI:10.1016/j.jss.2010.05.022 |
| [25] | Andrade E C, Machida F, Kim D S, et al. Modeling and analyzing server system with rejuvenation through SYSML and stochastic reward nets[C]// 2011 Sixth International Conference on Reliability and Security, IEEE, 2011: 161-168. https://www.computer.org/csdl/proceedings/ares/2011/4485/00/4485a161-abs.html |
| [26] | Eto H, Dohi T, Ma J. Simulation-based optimization approach for software cost model with rejuvenation[C]// Autonomic and Trusted Computing. Springer Berlin Heidelberg, 2008, 5060: 206-218. http://dl.acm.org/citation.cfm?id=1424717 |
| [27] | Garg S, Van Moorsel A, Vaidyanathan K, et al. A methodology for detection and estimation of software aging[C]// The Ninth International Symposium on Software Reliability Engineering, IEEE, 1998: 283-292. http://dl.acm.org/citation.cfm?id=856162 |
| [28] | Machida F, Andrzejak A, Matias R, et al. On the effectiveness of Mann-Kendall test for detection of software aging[C]// 2013 IEEE International Symposium on Software Reliability Engineering Workshops, IEEE, 2013: 269-274. https://www.computer.org/csdl/proceedings/issrew/2013/2552/00/06688905-abs.html |
| [29] | Li L, Vaidyanathan K, Trivedi K S. An approach for estimation of software aging in a web server[C]// 2002 International Symposium on Empirical Software Engineering, IEEE, 2002: 91-100. http://ieeexplore.ieee.org/xpls/icp.jsp?arnumber=1166929 |
| [30] | Grottke M, Li L, Vaidyanathan K, et al. Analysis of software aging in a web server[J]. IEEE Transactions on Reliability, 2006, 55(3): 411–420. DOI:10.1109/TR.2006.879609 |
| [31] | Araujo J, Matos R, Maciel P, et al. Software rejuvenation in eucalyptus cloud computing infrastructure: A method based on time series forecasting and multiple thresholds[C]// 2011 IEEE Third International Workshop on Software Aging and Rejuvenation, IEEE, 2011: 38-43. |
| [32] | Hoffmann G A, Trivedi K S, Malek M. A best practice guide to resource forecasting for computing systems[J]. IEEE Transactions on Reliability, 2007, 56(4): 615–628. DOI:10.1109/TR.2007.909764 |
| [33] | Cotroneo D, Natella R, Pietrantuono R, et al. Software aging analysis of the linux operating system[C]// 2010 IEEE 21st International Symposium on Software Reliability Engineering, IEEE, 2010: 71-80. http://dl.acm.org/citation.cfm?id=1914413 |
| [34] | Cotroneo D, Orlando S, Pietrantuono R, et al. A measurement-based aging analysis of the JVM[J]. Software Testing, Verification and Reliability, 2013, 23(3): 199–239. DOI:10.1002/stvr.v23.3 |
| [35] | Cassidy K J, Gross K C, Malekpour A. Advanced pattern recognition for detection of complex software aging phenomena in online transaction processing servers[C]// International Conference on Dependable Systems and Networks, IEEE, 2002: 478-482. https://www.computer.org/csdl/proceedings/dsn/2002/1597/00/15970478-abs.html |
| [36] | Alonso J, Belanche L, Avresky D R. Predicting software anomalies using machine learning techniques[C]// 2011 10th IEEE International Symposium on Network Computing and Applications, IEEE, 2011: 163-170. https://www.computer.org/csdl/proceedings/nca/2011/4489/00/4489a163-abs.html |
| [37] | Matias R. An experimental study on software aging and rejuvenation in web servers[C]// 30th Annual International Computer Software and Applications Conference, IEEE, 2006: 189-196. https://www.researchgate.net/publication/232650313_An_Experimental_Study_on_Software_Aging_and_Rejuvenation_in_Web_Servers |
| [38] | Moura Silva L, Alonso J, Silva P, et al. Using virtualization to improve software rejuvenation[J]. IEEE Transactions on Computers, 2009, 58(11): 1525–1538. DOI:10.1109/TC.2009.119 |
| [39] | Shereshevsky M, Crowell J, Cukic B, et al. Software aging and multifractality of memory resources[C]// 43rd Annual IEEE/IFIP International Conference on Dependable Systems and Networks, IEEE, 2003: 721. https://www.researchgate.net/publication/232621016_Software_Aging_and_Multifractality_of_Memory_Resources |
| [40] | Andrzejak A, Silva L. Deterministic models of software aging and optimal rejuvenation schedules[C]// 10th IFIP/IEEE International Symposium on Integrated Network Management, IEEE, 2007: 159-168. http://ieeexplore.ieee.org/xpls/icp.jsp?arnumber=4258532 |
| [41] | Bao Y, Sun X, Trivedi K S. A workload-based analysis of software aging and rejuvenation[J]. IEEE Transactions on Reliability, 2005, 54(3): 541–548. DOI:10.1109/TR.2005.853442 |
| [42] | Bovenzi A, Cotroneo D, Pietrantuono R, et al. Workload characterization for software aging analysis[C]// 2011 IEEE 22nd International Symposium on Software Reliability Engineering, IEEE, 2011: 240-249. https://www.computer.org/csdl/proceedings/issre/2011/4568/00/4568a240-abs.html |
| [43] | Zhao J, Trivedi K S, Wang Y B, et al. Evaluation of software performance affected by aging[C]// 2010 IEEE Second International Workshop on Software Aging and Rejuvenation, IEEE, 2010: 1-6. http://ieeexplore.ieee.org/document/5722093/ |
| [44] | Monit[EB/OL]. http://mmonit.com/monit/. |
| [45] | Ganglia[EB/OL]. http://ganglia.sourceforge.net/. |
| [46] | Munin[EB/OL]. http://munin-monitoring.org/. |
| [47] | Nagios[EB/OL]. http://www.nagios.org/. |
| [48] | Kim D S, Yang C S, Park J S. Adaptation mechanisms for survivable sensor networks against denial of service attack[C]// The Second International Conference on Availability, Reliability and Security, IEEE, 2007: 575-579. http://dl.acm.org/citation.cfm?id=1250569 |
| [49] | Vaidyanathan K, Trivedi K S. A measurement-based model for estimation of resource exhaustion in operational software systems[C]// 10th International Symposium on Software Reliability Engineering, IEEE, 1999: 84-93. http://doi.ieeecomputersociety.org/resolve?ref_id=doi:10.1109/ISSRE.1999.809313&rfr_id=trans/tc/2009/11/ttc2009111525.htm |
| [50] | Weimer W. Exception-handling bugs in Java and a language extension to avoid them[C]// Advanced Topics in Exception Handling Techniques. Springer Berlin Heidelberg, 2006: 22-41. http://www.springerlink.com/content/jjp5542751364241 |
| [51] | Zhang H, Wu G, Chow K, et al. Detecting resource leaks through dynamical mining of resource usage patterns[C]// 2011 IEEE/IFIP 41st International Conference on Dependable Systems and Networks Workshops, IEEE, 2011: 265-270. http://dl.acm.org/citation.cfm?id=2057093 |
| [52] | Carrozza G, Cotroneo D, Natella R, et al. Memory leak analysis of mission-critical middleware[J]. Journal of Systems and Software, 2010, 83(9): 1556–1567. DOI:10.1016/j.jss.2010.05.027 |
| [53] | Ferreira T B, Matias R, Macedo A, et al. An experimental study on memory allocators in multicore and multithreaded applications[C]// 12th International Conference on Parallel and Distributed Computing, IEEE, 2011: 92-98. http://ieeexplore.ieee.org/document/6118957/ |
| [54] | Silva L, Madeira H, Silva J G. Software aging and rejuvenation in a SOAP-based server[C]// Fifth IEEE International Symposium on Network Computing and Applications, IEEE, 2006: 56-65. https://www.computer.org/csdl/proceedings/nca/2006/2640/00/26400056-abs.html |
| [55] | Macedo A, Ferreira T B, Matias R. The mechanics of memory-related software aging[C]// 2010 IEEE Second International Workshop on Software Aging and Rejuvenation, IEEE, 2010: 1-5. http://ieeexplore.ieee.org/document/5722097/ |
| [56] | Tai A T, Alkalai L, Chau S N. On-board preventive maintenance: a design-oriented analytic study for long-life applications[J]. Performance Evaluation, 1999, 35(3): 215–232. |
| [57] | Grottke M, Nikora A P, Trivedi K S. An empirical investigation of fault types in space mission system software[C]// 2010 IEEE/IFIP International Conference on Dependable Systems and Networks, IEEE, 2010: 447-456. http://ieeexplore.ieee.org/xpls/icp.jsp?arnumber=5544284 |
| [58] | Balakrishnan M, Puliafito A, Trivedi K, et al. Buffer losses vs. deadline violations for ABR traffic in an ATM switch: A computational approach[J]. Telecommunication Systems, 1997, 7(1-3): 105–123. |
| [59] | Liu Y, Trivedi K S, Ma Y, et al. Modeling and analysis of software rejuvenation in cable modem termination systems[C]// 13th International Symposium on Software Reliability Engineering, IEEE, 2002: 159-170. https://www.computer.org/csdl/proceedings/issre/2002/1763/00/17630159-abs.html |
| [60] | Liu Y, Ma Y, Han J J, et al. A proactive approach towards always-on availability in broadband cable networks[J]. Computer Communications, 2005, 28(1): 51–64. DOI:10.1016/j.comcom.2004.08.022 |
| [61] | Okamura H, Miyahara S. Rejuvenating communication network system under burst arrival circumstances[J]. IEICE Transactions on Communications, 2005, 88(12): 4498–4506. |
| [62] | Yoshimura T, Yamada H, Kono K. Can Linux be rejuvenated without reboots?[C]// 2011 IEEE Third International Workshop on Software Aging and Rejuvenation, IEEE, 2011: 50-55. http://ieeexplore.ieee.org/document/6141725/ |
| [63] | Bovenzi A, Alonso J, Yamada H, et al. Towards fast OS rejuvenation: An experimental evaluation of fast OS reboot techniques[C]// 2013 IEEE 24th International Symposium on Software Reliability Engineering, IEEE, 2013: 61-70. https://www.computer.org/csdl/proceedings/issre/2013/9999/00/06698905-abs.html |
| [64] | Ni Q, Sun W, Ma S. Memory leak detection in sun solaris os[C]// International Symposium on Computer Science and Computational Technology, IEEE, 2008: 703-707. http://dl.acm.org/citation.cfm?id=1493578 |
| [65] | Robb D. Defragmenting really speeds up Windows NT machines[J]. Spectrum, IEEE, 2000, 37(9): 74–77. DOI:10.1109/6.866288 |
| [66] | Park J, Choi B. Automated memory leakage detection in android based systems[J]. International Journal of Control and Automation, 2012, 5(2): 35–42. |
| [67] | Huang Y, Arsenault D, Sood A. SCIT-DNS: Critical infrastructure protection through secure DNS server dynamic updates[J]. Journal of High Speed Networks, 2006, 15(1): 5–19. |
| [68] | Antunes J, Neves N F, Veríssimo P J. Detection and prediction of resource-exhaustion vulnerabilities[C]// 19th International Symposium on Software Reliability Engineering, IEEE, 2008: 87-96. https://www.computer.org/csdl/proceedings/issre/2008/3405/00/3405a087-abs.html |
| [69] | Machida F, Nicola V F, Trivedi K S. Job completion time on a virtualized server subject to software aging and rejuvenation[C]// 2011 IEEE Third International Workshop on Software Aging and Rejuvenation, IEEE, 2011: 44-49. https://www.computer.org/csdl/proceedings/wosar/2011/4616/00/4616a044-abs.html |
| [70] | Nellitheertha H. Reboot Linux faster using kexec[Z]. Developer Works Technical Library, 2004. |
| [71] | Alonso J, Matias R, Vicente E, et al. A comparative evaluation of software rejuvenation strategies[C]// 2011 IEEE Third International Workshop on Software Aging and Rejuvenation, IEEE, 2011: 26-31. http://dl.acm.org/citation.cfm?id=2121922.2122242&coll=DL&dl=GUIDE&CFID=426226880&CFTOKEN=61633747 |
| [72] | Kourai K. Cachemind: Fast performance recovery using a virtual machine monitor[C]// 2010 International Conference on Dependable Systems and Networks Workshops, IEEE, 2010: 86-92. http://dl.acm.org/citation.cfm?id=1909533 |
| [73] | Machida F, Kim D S, Trivedi K S. Modeling and analysis of software rejuvenation in a server virtualized system[C]// 2010 IEEE Second International Workshop on Software Aging and Rejuvenation, IEEE, 2010: 1-6. http://dx.doi.org/10.1109/WOSAR.2010.5722098 |
| [74] | Avritzer A, Bondi A, Weyuker E J. Ensuring system performance for cluster and single server systems[J]. Journal of Systems and Software, 2007, 80(4): 441–454. DOI:10.1016/j.jss.2006.07.020 |
| [75] | Jain M. Availability analysis of software rejuvenation in active/standby cluster system[J]. International Journal of Industrial and Systems Engineering, 2015, 19(1): 75–93. DOI:10.1504/IJISE.2015.065948 |
| [76] | Park K, Kim S. Availability analysis and improvement of active/standby cluster systems using software rejuvenation[J]. Journal of Systems and Software, 2002, 61(2): 121–128. DOI:10.1016/S0164-1212(01)00107-8 |
| [77] | Silva L M, Alonso J, Silva P, et al. Using virtualization to improve software rejuvenation[C]// Sixth IEEE International Symposium on Network Computing and Applications, IEEE, 2007: 33-44. http://ieeexplore.ieee.org/xpls/icp.jsp?arnumber=4276604 |
| [78] | Matias R, Trivedi K S, Maciel P R M. Using accelerated life tests to estimate time to software aging failure[C]// 2010 IEEE 21st International Symposium on Software Reliability Engineering, IEEE, 2010: 211-219. http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5635037 |
| [79] | Matias R, Barbetta P A, Trivedi K S. Accelerated degradation tests applied to software aging experiments[J]. IEEE Transactions on Reliability, 2010, 59(1): 102–114. DOI:10.1109/TR.2009.2034292 |
| [80] | Candea G, Cutler J, Fox A, et al. Reducing recovery time in a small recursively restartable system[C]// International Conference on Dependable Systems and Networks, IEEE, 2002: 605-614. https://www.computer.org/csdl/proceedings/dsn/2002/1597/00/15970605-abs.html |
| [81] | Candea G, Kawamoto S, Fujiki Y, et al. Microreboot—A technique for cheap recovery[C]// Proc. Symp. on Operating Systems Design & Implementation, 2004: 31-44. http://dl.acm.org/citation.cfm?id=1251254.1251257 |
| [82] | Sundaram V, HomChaudhuri S, Garg S, et al. Improving dependability using shared supplementary memory and opportunistic micro rejuvenation in multi-tasking embedded systems[C]// 13th Pacific Rim International Symposium on Dependable Computing, IEEE, 2007: 240-247. http://dl.acm.org/citation.cfm?id=1345812 |
| [83] | Tai A T, Tso K S, Sanders W H, et al. A performability-oriented software rejuvenation framework for distributed applications[C]// Proceedings International Conference on Dependable Systems and Networks, IEEE, 2005: 570-579. http://dl.acm.org/citation.cfm?id=1078315 |
| [84] | Tsai T, Vaidyanathan K, Gross K. Low-overhead run-time memory leak detection and recovery[C]// 12th Pacific Rim International Symposium on Dependable Computing, IEEE, 2006: 329-340. http://dl.acm.org/citation.cfm?id=1194340&CFID=521523513&CFTOKEN=12446396 |
| [85] | Bobbio A, Sereno M, Anglano C. Fine grained software degradation models for optimal rejuvenation policies[J]. Performance Evaluation, 2001, 46(1): 45–62. DOI:10.1016/S0166-5316(01)00037-2 |
| [86] | Bond M D, McKinley K S. Tolerating memory leaks[J]. ACM Sigplan Notices, 2008, 43(10): 109–126. DOI:10.1145/1449955 |
| [87] | Gama K, Donsez D. Service coroner: A diagnostic tool for locating OSGI stale references[C]// 34th Euromicro Conference on Software Engineering and Advanced Applications, IEEE, 2008: 108-115. https://www.computer.org/csdl/proceedings/seaa/2008/3276/00/3276a108-abs.html |
| [88] | Jeong J, Seo E, Choi J, et al. KAL: kernel-assisted non-invasive memory leak tolerance with a general-purpose memory allocator[J]. Software: Practice and Experience, 2010, 40(8): 605–625. DOI:10.1002/spe.v40:8 |