专利名称：存储器消耗监控装置和存储器消耗监控方法
技术领域：
本发明涉及计算机技术领域，具体而言，涉及存储器消耗监控装置和存储器消耗监控方法。
背景技术：
目前多数企业管理软件均采用Java或者.net编写而成。其内存管理特点与上一代软件有区別。上一代软件的内存分配与释放均需要应用程序显式调用，并且在调用完成后立即生效(立即分配或者立即释放)。但是基于Java或者.net的程序并不是这样。它们的内存分配虽然仍然由应用程序调用，但是内存释放过程并不由应用程序代码控制，而是由托管内存管理器负责。托管内存管理器根据当前内存使用的情况自动释放不再使用的内存，并且重新整理内存空间结构，释放内存碎片。托管内存管理器释放不在使用的内 存，并重整理内存空间结构的过程被称为“垃圾回收”(GC, Garbage Collector)。企业管理软件中的应用服务器常常执行大量的服务请求任务。但是，在处理这些请求的过程中，只要有少数请求处理程序消耗相对较大量的存储器件，服务器性能也会急剧下降。为此，监控这些系统中的存储器消耗与请求相关性对于维持总体稳定是有用的。但是，当系统被高度利用时，监控存储器的活动本身会显著影响系统性能。相关技术中存在一些解决方案。例如直接监视应用服务器的内存提交量。但是对于托管程序来说，内存的释放过程是不可预期的。对于高压カ服务器，内存提交量总是会保持在一个相对固定的点。不能准确地反映这些内存提交量中，真正被程序使用的内存量。如果在监控内存提交量之前，強制要求GC回收所有不再使用的内存。随后再检查内存提交量。这样可以获得精确的存储器真实使用情況。但强制GC行为会暂停所有应用服务器工作线程，有时甚至时间长达数十秒。考虑到通常应用服务器的响应时间普遍低于I秒。显然这种方案对系统性能将产生显著的不良影响。其次，除了带有初始化动作的请求处理程序和另外ー些存在设计缺陷导致内存泄漏的请求处理程序。绝大多数请求处理程序虽然在执行过程中会分配内存，但是在处理完成后的一段事件内会释放这些内存。直接监控内存提交量不能发现在请求处理程序的执行过程中究竟分配了多少内存。因此，需要一种存储器消耗监控技术，可监控请求处理程序在执行过程中所分配的内容，且不会影响系统的性能。
发明内容
基于上述背景技术的考虑，本发明的ー个目的是提供一种存储器消耗监控装置，可监控请求处理程序在执行过程中所分配的内容，且不会影响系统的性能。根据本发明的ー个方面，提供了一种存储器消耗监控装置，用于监控处理器和存储器，包括监控单元，监控存储器垃圾收集事件和服务请求的发生；相关性分析単元，确定所述服务请求与所述存储器垃圾收集事件之间的相关性；报告单元，连接至所述相关性分析単元，根据所述相关性分析単元的分析结果报告所述服务请求中的可疑请求。在该技术方案中，可监控存储器垃圾收集事件和发生的服务请求，建立存储器垃圾收集事件与服务请求之间的关系，根据该关系可确定可疑请求。在上述技术方案中，优选的，所述相关性分析単元包括相关性确定子单元，确定在每个所述存储器垃圾收集事件定义的时间间隔内所发生的服务请求以及服务请求所对应的发生次数；计算子単元，根据所述时间间隔内所述存储器垃圾收集事件所收集到的内存总量，以及各服务请求的发生次数，获取各所述服务请求的内存分配量，将内存分配量最大的服务请求作为可疑请求。根据存储器垃圾收集事件所收集到的内存总量以及各服务请求的次数可精确计算出每种服务请求所分配到的内存，避免了直接监控内存提交量不能发现在请求处理程序的执行过程中究竟分配了多少内存的问题，同时在相对精确的获得每种服务请求的内存分配情况同时，也尽可能减轻对系统的负担。在上述技术方案中，优选的，所述时间间隔的时段数大于等于所述服务请求的数 量。若服务请求的应用相关地址有多种，则需监控多个时间间隔，才能获取每种应用相关地址对应的服务请求所对应的内存量，也就是说，随着监控时段的増加，统计将越来越精确。在上述任一技术方案中，优选的，还可以包括提取单元，连接至所述相关性分析单元，根据所述服务请求的协议规范从所述服务请求中提取出应用相关地址，将所述应用相关地址作为所述服务请求的数据供所述相关性分析単元使用。服务请求多种多样，不同的协议有各自的规范，而应用相关地址才是本方案中所需要的，因此在服务请求中提取出应用相关地址，利用该应用相关地址来代表ー种服务请求。在上述任一技术方案中，优选的，所述相关性分析单元还包括排除子単元，若所述应用相关地址是第一次被分析，则排除所述应用相关地址对应的服务请求所在的时间间隔时段内的所有存储器垃圾收集事件和所有服务请求。在分解出应用相关地址后，需要判断该应用相关地址是否是第一次被分析，如果是，则考虑到很多请求处理过程都会在第一次请求发生时初始化ー些内存数据，因此，在本方案中将排除首次发现的请求，并且排除该请求所在时段内的所有存储器垃圾回收事件和服务请求。根据本发明的另一方面，还提供了一种存储器消耗监控方法，包括监控存储器垃圾收集事件和服务请求的发生；确定所述服务请求与所述存储器垃圾收集事件之间的相关性；根据所述相关性报告所述服务请求中的可疑请求。在该技术方案中，可监控存储器垃圾收集事件和发生的服务请求，建立存储器垃圾收集事件与服务请求之间的关系，根据该关系可确定可疑请求。在上述任一技术方案中，优选的，所述确定所述服务请求与所述存储器垃圾收集事件之间的相关性的步骤包括确定在每个所述存储器垃圾收集事件定义的时间间隔内所发生的服务请求以及服务请求所对应的发生次数；根据所述时间间隔内所述存储器垃圾收集事件所收集到的内存总量，以及各服务请求的发生次数，获取各所述服务请求的内存分配量，将内存分配量最大的服务请求作为可疑请求。根据存储器垃圾收集事件所收集到的内存总量以及各服务请求的次数可精确计算出每种服务请求所分配到的内存，避免了直接监控内存提交量不能发现在请求处理程序的执行过程中究竟分配了多少内存的问题，也提高了计算速度，减轻对系统的负担。在上述任一技术方案中，优选的，所述时间间隔的时段数大于等于所述服务请求的数量。若服务请求的应用相关地址有多种，则需监控多个时间间隔，才 能获取每种应用相关地址对应的服务请求所对应的内存量，也就是说，随着监控时段的増加，统计将越来越精确。在上述任一技术方案中，优选的，根据所述服务请求的协议规范从所述服务请求中提取出应用相关地址，将所述应用相关地址作为所述服务请求的数据供分析使用。服务请求多种多样，不同的协议有各自的规范，而应用相关地址才是本方案中所需要的，因此在服务请求中提取出应用相关地址，利用该应用相关地址来代表ー种服务请求。在上述任一技术方案中，优选的，若所述应用相关地址是第一次被分析，则排除所述应用相关地址对应的服务请求所在的时间间隔时段内的所有存储器垃圾收集事件和所有服务请求。在分解出应用相关地址后，需要判断该应用相关地址是否是第一次被分析，如果是，则考虑到很多请求处理过程都会在第一次请求发生时初始化ー些内存数据，因此，在本方案中将被排除首次发现的服务请求，并且排除该请求所在时段内的所有存储器垃圾回收事件和服务请求。根据本发明的技术方案，能准确反映内存提交量中真正被程序使用的内存量，可发现在请求处理程序的执行过程中究竟分配了多少内存，且不会影响系统的性能。
图I示出了根据本发明的实施例的存储器消耗监控装置的框图；图2示出了根据本发明的实施例的存储器消耗监控装置的示意图；以及图3示出了根据本发明的实施例的存储器消耗监控装置方法的流程图；图4示出了根据本发明的实施例的存储器消耗监控装置方法的流程图。
具体实施例方式为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式
对本发明进行进一歩的详细描述。在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明并不限于下面公开的具体实施例的限制。图I示出了根据本发明的实施例的存储器消耗监控装置的框图。如图I所示，根据本发明的实施例的存储器消耗监控装置100，用于监控处理器和存储器，包括监控单元102，监控存储器垃圾收集事件和服务请求的发生；相关性分析单元104，确定服务请求与存储器垃圾收集事件之间的相关性；报告单元106，连接至相关性分析単元104，根据相关性分析単元104的分析结果报告服务请求中的可疑请求。在该技术方案中，可监控存储器垃圾收集事件和发生的服务请求，建立存储器垃圾收集事件与服务请求之间的关系，根据该关系可确定可疑请求。在上述技术方案中，优选的，相关性分析单元104包括相关性确定子单元1042，确定在每个存储器垃圾收集事件定义的时间间隔内所发生的服务请求以及服务请求所对应的发生次数；计算子单元1044，根据时间间隔内存储器垃圾收集事件所收集到的内存总量，以及各服务请求的发生次数，获取各服务请求的内存分配量，将内存分配量最大的服务请求作为可疑请求。根据存储器垃圾收集事件所收集到的内存总量以及各服务请求的次数可精确计算出每种服务请求所分配到的内存，避免了直接监控内存提交量不能发现在请求处理程序的执行过程中究竟分配了多少内存的问题，也提高了计算速度，减轻对系统的负担。
在上述技术方案中，优选的，时间间隔的时段数大于等于服务请求的数量。若服务请求的应用相关地址有多种，则需监控多个时间间隔，才能获取每种应用相关地址对应的服务请求所对应的内存量，也就是说，随着监控时段的増加，统计将越来越精确。在上述任一技术方案中，优选的，还可以包括提取单元108，连接至相关性分析单元104，根据服务请求的协议规范从服务请求中提取出应用相关地址，将应用相关地址作为服务请求的数据供相关性分析単元104使用。服务请求多种多样，不同的协议有各自的规范，而应用相关地址才是本方案中所需要的，因此在服务请求中提取出应用相关地址，利用该应用相关地址来代表ー种服务请求。在上述任一技术方案中，优选的，相关性分析単元104还包括排除子単元1046，若应用相关地址是第一次被分析，则排除应用相关地址对应的服务请求所在的时间间隔时段内的所有存储器垃圾收集事件和所有服务请求。在分解出应用相关地址后，需要判断该应用相关地址是否是第一次被分析，如果是，则考虑到很多请求处理过程都会在第一次请求发生时初始化ー些内存数据，因此，在本方案中将排除首次发现的请求，并且排除该请求所在时段内的所有存储器垃圾回收事件和服务请求。图2示出了根据本发明的实施例的存储器消耗监控装置的示意图。服务请求发生吋，处理器204用于处理服务请求过程，随着所为响应的存储器分配，存储器垃圾回收事件也将发生。当请求和事件发生时，可以在对性能产生很小影响下将它们的相关信息存档。记录的事件周期可以存在2种方法。在选定的时间周期T内，例如T=I分钟。记录GC事件与请求事件。此后每个相同的时间周期T内都同样的记录GC事件和请求事件。存储器206用于记录与存储器垃圾回收事件相关联的事件信息，从而，与不同的存储器垃圾回收事件相关联的开始时间、结束时间都可以存储在其中。如图2中所示，存储器消耗监控装置可集成在系统服务器200中，与该系统服务器200还连接有显示器202。在本实施例中，周期T的选择需要远大于普通请求的处理时间和GC事件发生频率。例如，如果每请求花费20毫秒，而事件周期选择为I分钟。在这种情况下，记录请求的完成时间，还是记录请求的到达时间，对于时段T来说是几乎没有区别的。只是在具体实现上，全部请求使用同样的标准即可，全部记录请求到达时间，或者全部记录请求完成时间。在监控过程中，首先对服务请求进行參数化分解。服务请求多种多样，但是无论是基于SOA、SOAP、HTTP还是其他服务请求的协议，都能归结为协议描述、服务器地址、应用相关地址、请求參数四部分。例如某HTTP GET请求，请求的URL (访问请求)为http://host:8080/U9/GetBiIIDetaiI. aspx BillID=l。可以根据协议将其分割为协议描述http://; 服务器地址host:8080 ;应用相关地址/U9/GetBillDetail.aspx ；请求參数Bi11 ID=I。不同的协议都有各自的规范，可根据协议规范提取其中的应用相关地址。在某些文献中，也会将应用相关地址称作应用相关URL。在这四部分中，只有应用相关地址是本方案需要的，它与存储器分配过程紧密相关。下面解释对服务请求进行參数化分解的原因。假如GetBillDetail. aspx DocCode=l 和 GetBillDetail. aspx DocCode=2 这两个URL分别是获取订单I的详细信息和订单2的详细信息。获取不同用户的处理过程是相同的，所以对于应用服务器来说应是同一功能的不同參数。由于两个请求的URL不同，它会识别为不同的请求。根据人们的操作习惯，很少有人会针对同一张单据反复查看。所以应用服务器很难出现功能和參数正好都相同的情況，即URL很难重复。在具体的实践中将无法得到累计的迭代结果，进而使得分析可能是低效甚至无效的。所以需要首先将URL进行參数化分解。将URL中的应用相关URL从URL中提取出来。对于这个例子，这两个服务请求的应用相关URL都将是GetBillDetail. aspx。在分解出应用相关地址后，首先需要判断该应用相关地址是否是第一次被分析。如果是，考虑到很多请求处理过程都会在第一次请求发生时初始化一些内存数据。所以同类(相同应用相关地址)第一次发生时，往往伴随相对多的内存分配。因此，在本实施例中，将排除首次发现的服务请求。需要说明的是，排除并不是仅仅排除掉这条请求记录，而是排除该请求所在时段的所有GC事件和服务请求。由于某个时段内多个请求并行执行，所以很难从内存占用总量上直接获得某个具体请求的内存分配情況。所以如果仅仅考虑ー个时段内的监控记录。无法确定时段内具体某个请求的内存分配情况，也无法建立GC事件的数量与具体服务请求之间的关系。但是通过累计多个时段的监控记录，则可以找到内存分配明显多于其他请求的特殊请求。而随着监控时段的增多，统计将越来越精确。举例说明GC事件与具体服务请求之间的相关性判断方法。例如，在某时段Tl中。发现了 I次应用相关地址A、I次应用相关地址B和4次应用相关地址C。而在这个时段内，GC事件收集到的内存总量为45兆字节。同理，在时段T2和T3中也进行了记录。记录列表如下所示
权利要求
1.一种存储器消耗监控装置，用于监控处理器和存储器，其特征在于，包括 监控单元，监控存储器垃圾收集事件和服务请求的发生； 相关性分析単元，确定所述服务请求与所述存储器垃圾收集事件之间的相关性； 报告单元，连接至所述相关性分析単元，根据所述相关性分析単元的分析结果报告所述服务请求中的可疑请求。
2.根据权利要求I所述的存储器消耗监控装置，其特征在于，所述相关性分析単元包括 相关性确定子单元，确定在每个所述存储器垃圾收集事件定义的时间间隔内所发生的服务请求以及服务请求所对应的发生次数； 计算子単元，根据所述时间间隔内所述存储器垃圾收集事件所收集到的内存总量，以及各服务请求的发生次数，获取各所述服务请求的内存分配量，将内存分配量最大的服务请求作为可疑请求。
3.根据权利要求2所述的存储器消耗监控装置，其特征在于，所述时间间隔的时段数大于等于所述服务请求的数量。
4.根据权利要求2所述的存储器消耗监控装置，其特征在于，还包括提取单元，连接至所述相关性分析単元，根据所述服务请求的协议规范从所述服务请求中提取出应用相关地址，将所述应用相关地址作为所述服务请求的数据供所述相关性分析単元使用。
5.根据权利要求4所述的存储器消耗监控装置，其特征在于，所述相关性分析单元还包括排除子単元，若所述应用相关地址是第一次被分析，则排除所述应用相关地址对应的服务请求所在的时间间隔时段内的所有存储器垃圾收集事件和所有服务请求。
6.—种存储器消耗监控方法,其特征在于,包括 监控存储器垃圾收集事件和服务请求的发生； 确定所述服务请求与所述存储器垃圾收集事件之间的相关性； 根据所述相关性报告所述服务请求中的可疑请求。
7.根据权利要求6所述的存储器消耗监控方法，其特征在干，所述确定所述服务请求与所述存储器垃圾收集事件之间的相关性的步骤包括确定在每个所述存储器垃圾收集事件定义的时间间隔内所发生的服务请求以及服务请求所对应的发生次数； 根据所述时间间隔内所述存储器垃圾收集事件所收集到的内存总量，以及各服务请求的发生次数，获取各所述服务请求的内存分配量，将内存分配量最大的服务请求作为可疑请求。
8.根据权利要求7所述的存储器消耗监控方法，其特征在于，所述时间间隔的时段数大于等于所述服务请求的数量。
9.根据权利要求7所述的存储器消耗监控方法，其特征在于，根据所述服务请求的协议规范从所述服务请求中提取出应用相关地址，将所述应用相关地址作为所述服务请求的数据供分析使用。
10.根据权利要求9所述的存储器消耗监控方法，其特征在于，若所述应用相关地址是第一次被分析，则排除所述应用相关地址对应的服务请求所在的时间间隔时段内的所有存储器垃圾收集事件和所有服务请求。
全文摘要
本发明提供了一种存储器消耗监控装置，用于监控处理器和存储器，包括监控单元，监控存储器垃圾收集事件和服务请求的发生；相关性分析单元，确定所述服务请求与所述存储器垃圾收集事件之间的相关性；报告单元，连接至所述相关性分析单元，根据所述相关性分析单元的分析结果报告所述服务请求中的可疑请求。根据本发明的技术方案，可高效的获取存储器的使用情况，甄别出对系统资源(存储器)消耗巨大的请求处理程序，从而还可为提高服务器的性能提供有力保障。本发明还提供了一种存储器消耗监控方法。
文档编号G06F11/34GK102819483SQ20121021799
公开日2012年12月12日 申请日期2012年6月27日 优先权日2012年6月27日
发明者杨历 申请人:用友软件股份有限公司