CN102819483B - 存储器消耗监控装置和存储器消耗监控方法 - Google Patents

Abstract

本发明提供了一种存储器消耗监控装置，用于监控处理器和存储器，包括：监控单元，监控存储器垃圾收集事件和服务请求的发生；相关性分析单元，确定所述服务请求与所述存储器垃圾收集事件之间的相关性；报告单元，连接至所述相关性分析单元，根据所述相关性分析单元的分析结果报告所述服务请求中的可疑请求。根据本发明的技术方案，可高效的获取存储器的使用情况，甄别出对系统资源（存储器）消耗巨大的请求处理程序，从而还可为提高服务器的性能提供有力保障。本发明还提供了一种存储器消耗监控方法。

Description

存储器消耗监控装置和存储器消耗监控方法

技术领域

本发明涉及计算机技术领域，具体而言，涉及存储器消耗监控装置和存储器消耗监控方法。

背景技术

目前多数企业管理软件均采用Java或者.net编写而成。其内存管理特点与上一代软件有区别。上一代软件的内存分配与释放均需要应用程序显式调用，并且在调用完成后立即生效（立即分配或者立即释放）。但是基于Java或者.net的程序并不是这样。它们的内存分配虽然仍然由应用程序调用，但是内存释放过程并不由应用程序代码控制，而是由托管内存管理器负责。托管内存管理器根据当前内存使用的情况自动释放不再使用的内存，并且重新整理内存空间结构，释放内存碎片。托管内存管理器释放不在使用的内存，并重整理内存空间结构的过程被称为“垃圾回收”（GC，Garbage Collector）。

企业管理软件中的应用服务器常常执行大量的服务请求任务。但是，在处理这些请求的过程中，只要有少数请求处理程序消耗相对较大量的存储器件，服务器性能也会急剧下降。为此，监控这些系统中的存储器消耗与请求相关性对于维持总体稳定是有用的。但是，当系统被高度利用时，监控存储器的活动本身会显著影响系统性能。

相关技术中存在一些解决方案。例如直接监视应用服务器的内存提交量。但是对于托管程序来说，内存的释放过程是不可预期的。对于高压力服务器，内存提交量总是会保持在一个相对固定的点。不能准确地反映这些内存提交量中，真正被程序使用的内存量。

如果在监控内存提交量之前，强制要求GC回收所有不再使用的内存。随后再检查内存提交量。这样可以获得精确的存储器真实使用情况。但强制GC行为会暂停所有应用服务器工作线程，有时甚至时间长达数十秒。考虑到通常应用服务器的响应时间普遍低于1秒。显然这种方案对系统性能将产生显著的不良影响。

其次，除了带有初始化动作的请求处理程序和另外一些存在设计缺陷导致内存泄漏的请求处理程序。绝大多数请求处理程序虽然在执行过程中会分配内存，但是在处理完成后的一段事件内会释放这些内存。直接监控内存提交量不能发现在请求处理程序的执行过程中究竟分配了多少内存。

因此，需要一种存储器消耗监控技术，可监控请求处理程序在执行过程中所分配的内容，且不会影响系统的性能。

发明内容

基于上述背景技术的考虑，本发明的一个目的是提供一种存储器消耗监控装置，可监控请求处理程序在执行过程中所分配的内容，且不会影响系统的性能。

根据本发明的一个方面，提供了一种存储器消耗监控装置，用于监控处理器和存储器，包括：监控单元，监控存储器垃圾收集事件和服务请求的发生；相关性分析单元，确定所述服务请求与所述存储器垃圾收集事件之间的相关性；报告单元，连接至所述相关性分析单元，根据所述相关性分析单元的分析结果报告所述服务请求中的可疑请求。

在该技术方案中，可监控存储器垃圾收集事件和发生的服务请求，建立存储器垃圾收集事件与服务请求之间的关系，根据该关系可确定可疑请求。

在上述技术方案中，优选的，所述相关性分析单元包括：相关性确定子单元，确定在每个所述存储器垃圾收集事件定义的时间间隔内所发生的服务请求以及服务请求所对应的发生次数；计算子单元，根据所述时间间隔内所述存储器垃圾收集事件所收集到的内存总量，以及各服务请求的发生次数，获取各所述服务请求的内存分配量，将内存分配量最大的服务请求作为可疑请求。

根据存储器垃圾收集事件所收集到的内存总量以及各服务请求的次数可精确计算出每种服务请求所分配到的内存，避免了直接监控内存提交量不能发现在请求处理程序的执行过程中究竟分配了多少内存的问题，同时在相对精确的获得每种服务请求的内存分配情况同时，也尽可能减轻对系统的负担。

在上述技术方案中，优选的，所述时间间隔的时段数大于等于所述服务请求的数量。

若服务请求的应用相关地址有多种，则需监控多个时间间隔，才能获取每种应用相关地址对应的服务请求所对应的内存量，也就是说，随着监控时段的增加，统计将越来越精确。

在上述任一技术方案中，优选的，还可以包括提取单元，连接至所述相关性分析单元，根据所述服务请求的协议规范从所述服务请求中提取出应用相关地址，将所述应用相关地址作为所述服务请求的数据供所述相关性分析单元使用。

服务请求多种多样，不同的协议有各自的规范，而应用相关地址才是本方案中所需要的，因此在服务请求中提取出应用相关地址，利用该应用相关地址来代表一种服务请求。

在上述任一技术方案中，优选的，所述相关性分析单元还包括排除子单元，若所述应用相关地址是第一次被分析，则排除所述应用相关地址对应的服务请求所在的时间间隔时段内的所有存储器垃圾收集事件和所有服务请求。

在分解出应用相关地址后，需要判断该应用相关地址是否是第一次被分析，如果是，则考虑到很多请求处理过程都会在第一次请求发生时初始化一些内存数据，因此，在本方案中将排除首次发现的请求，并且排除该请求所在时段内的所有存储器垃圾回收事件和服务请求。

根据本发明的另一方面，还提供了一种存储器消耗监控方法，包括：监控存储器垃圾收集事件和服务请求的发生；确定所述服务请求与所述存储器垃圾收集事件之间的相关性；根据所述相关性报告所述服务请求中的可疑请求。

在该技术方案中，可监控存储器垃圾收集事件和发生的服务请求，建立存储器垃圾收集事件与服务请求之间的关系，根据该关系可确定可疑请求。

在上述任一技术方案中，优选的，所述确定所述服务请求与所述存储器垃圾收集事件之间的相关性的步骤包括：确定在每个所述存储器垃圾收集事件定义的时间间隔内所发生的服务请求以及服务请求所对应的发生次数；根据所述时间间隔内所述存储器垃圾收集事件所收集到的内存总量，以及各服务请求的发生次数，获取各所述服务请求的内存分配量，将内存分配量最大的服务请求作为可疑请求。

根据存储器垃圾收集事件所收集到的内存总量以及各服务请求的次数可精确计算出每种服务请求所分配到的内存，避免了直接监控内存提交量不能发现在请求处理程序的执行过程中究竟分配了多少内存的问题，也提高了计算速度，减轻对系统的负担。

在上述任一技术方案中，优选的，所述时间间隔的时段数大于等于所述服务请求的数量。

若服务请求的应用相关地址有多种，则需监控多个时间间隔，才能获取每种应用相关地址对应的服务请求所对应的内存量，也就是说，随着监控时段的增加，统计将越来越精确。

在上述任一技术方案中，优选的，根据所述服务请求的协议规范从所述服务请求中提取出应用相关地址，将所述应用相关地址作为所述服务请求的数据供分析使用。

服务请求多种多样，不同的协议有各自的规范，而应用相关地址才是本方案中所需要的，因此在服务请求中提取出应用相关地址，利用该应用相关地址来代表一种服务请求。

在上述任一技术方案中，优选的，若所述应用相关地址是第一次被分析，则排除所述应用相关地址对应的服务请求所在的时间间隔时段内的所有存储器垃圾收集事件和所有服务请求。

在分解出应用相关地址后，需要判断该应用相关地址是否是第一次被分析，如果是，则考虑到很多请求处理过程都会在第一次请求发生时初始化一些内存数据，因此，在本方案中将被排除首次发现的服务请求，并且排除该请求所在时段内的所有存储器垃圾回收事件和服务请求。

根据本发明的技术方案，能准确反映内存提交量中真正被程序使用的内存量，可发现在请求处理程序的执行过程中究竟分配了多少内存，且不会影响系统的性能。

附图说明

图1示出了根据本发明的实施例的存储器消耗监控装置的框图；

图2示出了根据本发明的实施例的存储器消耗监控装置的示意图；以及

图3示出了根据本发明的实施例的存储器消耗监控装置方法的流程图；

图4示出了根据本发明的实施例的存储器消耗监控装置方法的流程图。

具体实施方式

为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式对本发明进行进一步的详细描述。

在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明并不限于下面公开的具体实施例的限制。

图1示出了根据本发明的实施例的存储器消耗监控装置的框图。

如图1所示，根据本发明的实施例的存储器消耗监控装置100，用于监控处理器和存储器，包括：监控单元102，监控存储器垃圾收集事件和服务请求的发生；相关性分析单元104，确定服务请求与存储器垃圾收集事件之间的相关性；报告单元106，连接至相关性分析单元104，根据相关性分析单元104的分析结果报告服务请求中的可疑请求。

在该技术方案中，可监控存储器垃圾收集事件和发生的服务请求，建立存储器垃圾收集事件与服务请求之间的关系，根据该关系可确定可疑请求。

在上述技术方案中，优选的，相关性分析单元104包括：相关性确定子单元1042，确定在每个存储器垃圾收集事件定义的时间间隔内所发生的服务请求以及服务请求所对应的发生次数；计算子单元1044，根据时间间隔内存储器垃圾收集事件所收集到的内存总量，以及各服务请求的发生次数，获取各服务请求的内存分配量，将内存分配量最大的服务请求作为可疑请求。

根据存储器垃圾收集事件所收集到的内存总量以及各服务请求的次数可精确计算出每种服务请求所分配到的内存，避免了直接监控内存提交量不能发现在请求处理程序的执行过程中究竟分配了多少内存的问题，也提高了计算速度，减轻对系统的负担。

在上述技术方案中，优选的，时间间隔的时段数大于等于服务请求的数量。

若服务请求的应用相关地址有多种，则需监控多个时间间隔，才能获取每种应用相关地址对应的服务请求所对应的内存量，也就是说，随着监控时段的增加，统计将越来越精确。

在上述任一技术方案中，优选的，还可以包括提取单元108，连接至相关性分析单元104，根据服务请求的协议规范从服务请求中提取出应用相关地址，将应用相关地址作为服务请求的数据供相关性分析单元104使用。

服务请求多种多样，不同的协议有各自的规范，而应用相关地址才是本方案中所需要的，因此在服务请求中提取出应用相关地址，利用该应用相关地址来代表一种服务请求。

在上述任一技术方案中，优选的，相关性分析单元104还包括排除子单元1046，若应用相关地址是第一次被分析，则排除应用相关地址对应的服务请求所在的时间间隔时段内的所有存储器垃圾收集事件和所有服务请求。

在分解出应用相关地址后，需要判断该应用相关地址是否是第一次被分析，如果是，则考虑到很多请求处理过程都会在第一次请求发生时初始化一些内存数据，因此，在本方案中将排除首次发现的请求，并且排除该请求所在时段内的所有存储器垃圾回收事件和服务请求。

图2示出了根据本发明的实施例的存储器消耗监控装置的示意图。

服务请求发生时，处理器204用于处理服务请求过程，随着所为响应的存储器分配，存储器垃圾回收事件也将发生。当请求和事件发生时，可以在对性能产生很小影响下将它们的相关信息存档。记录的事件周期可以存在2种方法。在选定的时间周期T内，例如T=1分钟。记录GC事件与请求事件。此后每个相同的时间周期T内都同样的记录GC事件和请求事件。存储器206用于记录与存储器垃圾回收事件相关联的事件信息，从而，与不同的存储器垃圾回收事件相关联的开始时间、结束时间都可以存储在其中。

如图2中所示，存储器消耗监控装置可集成在系统服务器200中，与该系统服务器200还连接有显示器202。

在本实施例中，周期T的选择需要远大于普通请求的处理时间和GC事件发生频率。例如，如果每请求花费20毫秒，而事件周期选择为1分钟。在这种情况下，记录请求的完成时间，还是记录请求的到达时间，对于时段T来说是几乎没有区别的。只是在具体实现上，全部请求使用同样的标准即可，全部记录请求到达时间，或者全部记录请求完成时间。

在监控过程中，首先对服务请求进行参数化分解。服务请求多种多样，但是无论是基于SOA、SOAP、HTTP还是其他服务请求的协议，都能归结为协议描述、服务器地址、应用相关地址、请求参数四部分。

例如某HTTP GET请求，请求的URL（访问请求）为：

http://host:8080/U9/GetBillDetail.aspx?BillID=1。可以根据协议将其分割为：

协议描述：http://；

服务器地址：host:8080；

应用相关地址：/U9/GetBillDetail.aspx；

请求参数：BillID=1。

不同的协议都有各自的规范，可根据协议规范提取其中的应用相关地址。在某些文献中，也会将应用相关地址称作应用相关URL。在这四部分中，只有应用相关地址是本方案需要的，它与存储器分配过程紧密相关。

下面解释对服务请求进行参数化分解的原因。

假如GetBillDetail.aspx?DocCode=1和GetBillDetail.aspx?DocCode=2这两个URL分别是获取订单1的详细信息和订单2的详细信息。获取不同用户的处理过程是相同的，所以对于应用服务器来说应是同一功能的不同参数。由于两个请求的URL不同，它会识别为不同的请求。根据人们的操作习惯，很少有人会针对同一张单据反复查看。所以应用服务器很难出现功能和参数正好都相同的情况，即URL很难重复。在具体的实践中将无法得到累计的迭代结果，进而使得分析可能是低效甚至无效的。所以需要首先将URL进行参数化分解。将URL中的应用相关URL从URL中提取出来。对于这个例子，这两个服务请求的应用相关URL都将是GetBillDetail.aspx。

在分解出应用相关地址后，首先需要判断该应用相关地址是否是第一次被分析。如果是，考虑到很多请求处理过程都会在第一次请求发生时初始化一些内存数据。所以同类（相同应用相关地址）第一次发生时，往往伴随相对多的内存分配。因此，在本实施例中，将排除首次发现的服务请求。需要说明的是，排除并不是仅仅排除掉这条请求记录，而是排除该请求所在时段的所有GC事件和服务请求。

由于某个时段内多个请求并行执行，所以很难从内存占用总量上直接获得某个具体请求的内存分配情况。所以如果仅仅考虑一个时段内的监控记录。无法确定时段内具体某个请求的内存分配情况，也无法建立GC事件的数量与具体服务请求之间的关系。但是通过累计多个时段的监控记录，则可以找到内存分配明显多于其他请求的特殊请求。而随着监控时段的增多，统计将越来越精确。举例说明GC事件与具体服务请求之间的相关性判断方法。

例如，在某时段T1中。发现了1次应用相关地址A、1次应用相关地址B和4次应用相关地址C。而在这个时段内，GC事件收集到的内存总量为45兆字节。同理，在时段T2和T3中也进行了记录。记录列表如下所示：

时段	GC	A	B	C	方程
						T1	45M	1	1	4	A+B+4C=45
T2	45M	0	1	8	0A+B+8C=45
						T3	45M	1	2	2	A+2B+2C=45

孤立的看每个时段，显然无法求解方程。但是将T1、T2、T3时段的方程组合成为方程组。显然只要方程的数量大于变量的数量，即可以求出方程组的唯一解。换句话说，只要足够时间的观察，就可以将具体请求执行程序的内存消耗计算出来。对于本例，计算出各服务请求所分配的内存量为：服务请求A=18，服务请求B=9，服务请求C=4.5。从而找出服务请求A的内存分配明显多于其他请求的分配量。可通过显示器202报告显示可疑请求。直接用N元一次方程求解的方法即可得到请求的内存消耗。

所以，根据本发明的存储器消耗监控装置可以甄别出那些对系统资源（存储器）消耗巨大的请求处理程序，为找到程序瓶颈和弱点提供有力依据，因此，在监控的同时尽可能减少对系统的干扰，从而为提高系统性能提供有力保障。

图3示出了根据本发明的实施例的存储器消耗监控装置方法的流程图。

如图3所示，根据本发明的实施例的存储器消耗监控方法，包括：步骤302，监控存储器垃圾收集事件和服务请求的发生；步骤304，确定服务请求与存储器垃圾收集事件之间的相关性；步骤306，根据相关性报告服务请求中的可疑请求。

在该技术方案中，可监控存储器垃圾收集事件和发生的服务请求，建立存储器垃圾收集事件与服务请求之间的关系，根据该关系可确定可疑请求。

在上述任一技术方案中，优选的，步骤304具体包括：确定在每个存储器垃圾收集事件定义的时间间隔内所发生的服务请求以及服务请求所对应的发生次数；根据时间间隔内存储器垃圾收集事件所收集到的内存总量，以及各服务请求的发生次数，获取各服务请求的内存分配量，将内存分配量最大的服务请求作为可疑请求。

根据存储器垃圾收集事件所收集到的内存总量以及各服务请求的次数可精确计算出每种服务请求所分配到的内存，避免了直接监控内存提交量不能发现在请求处理程序的执行过程中究竟分配了多少内存的问题，也提高了计算速度，减轻对系统的负担。

在上述任一技术方案中，优选的，时间间隔的时段数大于等于服务请求类型的数量。

若服务请求的应用相关地址有多种，则需监控多个时间间隔，才能获取每种应用相关地址对应的服务请求所对应的内存量，也就是说，随着监控时段的增加，统计将越来越精确。

在上述任一技术方案中，优选的，根据服务请求的协议规范从服务请求中提取出应用相关地址，将应用相关地址作为服务请求的数据供分析使用。

服务请求多种多样，不同的协议有各自的规范，而应用相关地址才是本方案中所需要的，因此在服务请求中提取出应用相关地址，利用该应用相关地址来代表一种服务请求。

在上述任一技术方案中，优选的，若应用相关地址是第一次被分析，则排除应用相关地址对应的服务请求所在的时间间隔时段内的所有存储器垃圾收集事件和所有服务请求。

在分解出应用相关地址后，需要判断该应用相关地址是否是第一次被分析，如果是，则考虑到很多请求处理过程都会在第一次请求发生时初始化一些内存数据，因此，在本方案中将被排除首次发现的服务请求，并且排除该请求所在时段内的所有存储器垃圾回收事件和服务请求。

下面结合图4进一步说明根据本发明的存储器消耗监控方法。如图4所示，在步骤11，监控存储器垃圾回收事件和服务请求的发生并记录监控情况。在步骤12，对服务请求进行参数化分解，分解出应用相关地址，具体分解方法参见图2对应的实施例中的描述。在步骤13，判断该应用相关地址是否是首次请求。如果是，则删除该时段内所有的存储器垃圾回收事件以及服务请求的所有记录，回复步骤11重新开始监控存储器垃圾回收事件以及服务请求的发生。如果不是首次请求，则进入步骤14，进行内存组合分析。具体分析方法参考图2对应的实施例中的描述。在步骤15，根据分析结果判断是否有可疑的服务请求，若有，则进入步骤16，报告可疑请求，若没有可疑请求，则回到步骤11。

以上结合附图详细说明了根据本发明的技术方案，能准确反映内存提交量中真正被程序使用的内存量，可发现在请求处理程序的执行过程中究竟分配了多少内存，且不会影响系统的性能。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种存储器消耗监控装置，用于监控处理器和存储器，其特征在于，包括：

监控单元，监控存储器垃圾收集事件和服务请求的发生；

相关性分析单元，确定所述服务请求与所述存储器垃圾收集事件之间的相关性；

报告单元，连接至所述相关性分析单元，根据所述相关性分析单元的分析结果报告所述服务请求中的可疑请求；

其中，所述相关性分析单元包括：

相关性确定子单元，确定在每个所述存储器垃圾收集事件定义的时间间隔内所发生的服务请求以及服务请求所对应的发生次数；

计算子单元，根据所述时间间隔内所述存储器垃圾收集事件所收集到的内存总量，以及各服务请求的发生次数，获取各所述服务请求的内存分配量，将内存分配量最大的服务请求作为可疑请求。

2.根据权利要求1所述的存储器消耗监控装置，其特征在于，所述时间间隔的时段数大于等于所述服务请求的数量。

3.根据权利要求1所述的存储器消耗监控装置，其特征在于，还包括提取单元，连接至所述相关性分析单元，根据所述服务请求的协议规范从所述服务请求中提取出应用相关地址，将所述应用相关地址作为所述服务请求的数据供所述相关性分析单元使用。

4.根据权利要求3所述的存储器消耗监控装置，其特征在于，所述相关性分析单元还包括排除子单元，若所述应用相关地址是第一次被分析，则排除所述应用相关地址对应的服务请求所在的时间间隔时段内的所有存储器垃圾收集事件和所有服务请求。

5.一种存储器消耗监控方法，其特征在于，包括：

监控存储器垃圾收集事件和服务请求的发生；

确定所述服务请求与所述存储器垃圾收集事件之间的相关性；

根据所述相关性报告所述服务请求中的可疑请求；

其中，所述确定所述服务请求与所述存储器垃圾收集事件之间的相关性的步骤包括：确定在每个所述存储器垃圾收集事件定义的时间间隔内所发生的服务请求以及服务请求所对应的发生次数；

根据所述时间间隔内所述存储器垃圾收集事件所收集到的内存总量，以及各服务请求的发生次数，获取各所述服务请求的内存分配量，将内存分配量最大的服务请求作为可疑请求。

6.根据权利要求5所述的存储器消耗监控方法，其特征在于，所述时间间隔的时段数大于等于所述服务请求的数量。

7.根据权利要求5所述的存储器消耗监控方法，其特征在于，根据所述服务请求的协议规范从所述服务请求中提取出应用相关地址，将所述应用相关地址作为所述服务请求的数据供分析使用。

8.根据权利要求7所述的存储器消耗监控方法，其特征在于，若所述应用相关地址是第一次被分析，则排除所述应用相关地址对应的服务请求所在的时间间隔时段内的所有存储器垃圾收集事件和所有服务请求。