CN106330990A - B/s结构的性能监控分析系统和方法 - Google Patents

Abstract

本申请公开一种B/S结构的性能监控分析系统和方法，其中，所述系统包括：控制模块、性能数据客户端节点模块、性能监控数据收集模块；所述控制模块，用于采用双通道消息通讯方式向所述性能数据客户端节点模块发送控制消息；所述性能数据客户端节点模块，用于根据接收到的控制消息采集Java服务器的性能数据；所述性能监控数据收集模块，用于收集Java服务器的性能数据并存储。通过本申请能够快速、实时、高效的定位出服务器瓶颈所在，且持久化保存，为优化提供数据依据和对比。

Description

B/S结构的性能监控分析系统和方法

技术领域

本申请涉及计算机技术领域，尤其涉及一种B/S结构的性能监控分析系统和方法。

背景技术

现有技术中对于Java服务器的性能分析工具主要包括：客户端方式、日志统计方式和命令行方式等三种类型。

其中，客户端方式需要在Windows系统或者Linux系统上安装客户端，然后和服务器上的后台服务进行通讯，获取所需的监控分析数据，这种方式的缺点主要包括：

(1)需要安装客户端，如果更换机器，还需要再重新安装客户端；

(2)操作独占。用户只能在这台安装了客户端的机器上操作和查看，而且这台机器不能再进行其他操作；

(3)分析后的结果文件保存后，也需要客户端来读取和识别，无法共享；其他人想看仍然要安装客户端，同时把文件拷贝过来打开，非常不方便；

(4)分析数据和回传数据的代理模块引入在服务器进程当中，相互之间造成资源争抢，同时对数据也会有干扰；

(5)分析属于字节码全量分析，开启后对性能影响很大，不适合线上监控和使用。

命令行方式虽然不需要安装客户端，但是需要在服务器端执行，这种方式的缺点主要包括：

(1)需要服务器的权限才可以登录执行，存在安全问题。

(2)需要提前知道要监控的方法和类，指定类和方法进行监控和分析。

(3)无法进行实时监控，必须要等到监控工作完成后才可以搜集数据和展示，不利于排查问题。

(4)资源独占。

(5)监控基于日志文件，灵活性不强。

(6)全方法扫描，性能消耗大。

(7)监控范围有限，只能统计时间消耗，无法计算CPU消耗。

日志统计的方式就更加原始，其缺点主要包括：

(1)需要在代码中明文埋点或者配置中增加参数，侵入性强。

(2)分析的数据在日志中存放，无法持久化，不灵活。

(3)统计工具不完善，展示方式不友好，不利于分析。

(4)监控范围有限，只能统计时间消耗，无法计算CPU消耗。

所以，在使用以上工具分析性能瓶颈的时候，存在以下问题：

(1)不实时。在方法中增加埋点代码，用于记录方法前后调用的时间信息、或放在内存、或放在日志中保存，然后输出，这种方法的缺点就是a.不能实时监控；b.需要开发代码，同时对所监控的应用代码逻辑了解，成本高；c.每次访问都要走该代码逻辑，耗时，耗IO资源；d.监控代码和服务器代码混合在一起，产生性能分析的混淆。

(2)侵入性。利用字节码反编译注入的方式。对代码有侵入性，同时对资源消耗也很大，每次调用都会执行，无法基于业务线程分析，会使其他线程的信息产生业务上的混淆，不支持采样。

(3)不灵活，无共享。客户端软件，需要安装，分析的文件无法共享，打开文件需要安装相应的客户端软件，不灵活。

(4)操作独占，无法共享操作资源。

(5)单方法，需要提前知道业务需要监控的方法，然后作为参数传入给工具，只能监控该方法的调用，无法实现整个方法递归查询。

(6)有干扰。分析数据和回传数据的代理模块引入在服务器进程当中，相互之间造成资源争抢，同时对数据也会有干扰。

发明内容

本申请的主要目的在于提供一种B/S结构的性能监控分析系统和方法，以克服现有技术中的上述问题。

根据本申请实施例提供了一种B/S结构的性能监控分析系统，其包括：控制模块、性能数据客户端节点模块、性能监控数据收集模块，

所述控制模块，用于采用双通道消息通讯方式向所述性能数据客户端节点模块发送控制消息；

所述性能数据客户端节点模块，设置于服务器中，用于根据接收到的控制指令采集服务器的性能数据；

所述性能监控数据收集模块，用于开启分析进程，对采集到的服务器的性能数据进行分析。

根据本申请实施例还提供一种B/S结构的性能监控分析方法，其包括：

采用双通道消息通讯方式发送控制消息；

根据接收到的控制指令采集服务器的性能数据；

开启分析进程，对采集到的服务器的性能数据进行分析。

与现有技术相比，根据本申请的技术方案，通过双通道消息控制方式实现了多种网络环境下的监控操作和数据采集，并且数据采集进程和服务器进程相对独立，相互之间不受影响，通过本申请能够快速、实时、高效的定位出服务器瓶颈所在，且持久化保存，为优化提供数据依据和对比。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请一个实施例的性能监控分析系统的结构框图；

图2是根据本申请另一实施例的性能监控分析系统的结构框图；

图3是根据本申请实施例的CPU数据分析以及生成CPU快照信息的流程图；

图4是根据本申请实施例的生成线程快照和开启内存分析的流程图；

图5是根据本申请实施例的性能监控分析方法的流程图；

图6A-图6D是根据本申请实施例的CPU数据采集和线程采集过程的流程图；

图7A和图7B是根据本申请实施例的详细描述内存采集过程的流程图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

根据本申请实施例，提供一种B/S结构的性能监控分析系统。该系统是一种分布式的性能自动化测试平台(Performance Automation Test Platform，简称PAP)，该测试平台基于B/S结构(Browser/Server，浏览器/服务器模式)，用户可以通过Web的方式，在任何时间和任何地点通过系统平台管理性能测试环境，配置性能监控，设置性能测试场景和测试任务，对目标实施压力测试。该平台能够自动分发测试任务和监控命令，并自动获取监控结果、测试结果，展示出来，为用户提供性能数据采集和分析依据。

图1是根据本申请一个实施例的B/S结构的性能监控分析系统的结构框图，如图1所示，所述性能监控分析系统包括：控制模块(Control)10、性能数据客户端节点模块(perf-agent)20、性能监控数据收集模块(Monitor)30，下面详细描述各模块的结构和功能。

所述控制模块10，用于采用双通道消息通讯方式向所述性能数据客户端节点模块20发送控制消息。在本申请实施例中，所述双通道消息通讯方式包括：套接字(Socket)消息通讯方式和消息队列(Message Queue，简称MQ)通讯方式，其中，Socket消息通讯方式的工作过程包括：

(1)性能数据客户端节点模块发起一个Socket监听线程，监听预定格式的开启消息和结束消息；

(2)控制模块发送一个预定格式的命令串，命令串的格式可以是“命令@WorkspaceKey”；

(3)性能数据客户端节点模块接收到开启消息(命令串的格式可以是start@Key)时，创建一个Key的采集任务，进行任务采集；

(4)性能数据客户端节点模块接收到结束消息(命令串的格式可以是stop@Key)时，提取出Key的采集任务，停止该任务。

MQ消息通讯方式的工作过程包括：

(1)性能数据客户端节点模块发起一个MQ监听线程，监听消息队列；

(2)控制模块发送消息给MQ。MQ支持Java对象的传输，消息对象包括“命令、WorkspaceKey”；

(3)性能数据客户端节点模块接收到开启消息时，创建一个key的采集任务，进行任务采集；

(4)性能数据客户端节点模块接收到结束消息时，提取出key的采集任务，停止该任务。

在实际应用中，需要根据不同的网络环境采用对应的消息通讯方式，Socket消息通讯方式传输速度快、稳定、开发成本低，适合于局域网环境；而MQ消息通讯方式的覆盖方位广、限制少、容灾配置、且支持离线存储，适用于广域网和复杂的网络环境。

所述性能数据客户端节点模块20，用于根据接收到的控制指令采集服务器的性能数据。具体地，性能数据客户端节点模块20接收到的控制指令包括但不限于：CPU数据采集、生成CPU快照信息、生成线程快照信息和内存数据采集等，下面根据接收到的控制指令的类型详细描述性能数据客户端节点模块20的处理过程：

接收到CPU数据采集的控制消息后，创建数据采集线程和数据回传线程，通过所述数据采集线程采集服务器的性能数据，并通过所述数据回传线程将采集到的性能数据传送至所述性能监控数据收集模块；所述数据采集线程启动后，每隔预定时间触发预先创建的数据采集器，所述数据采集器通过调用Java虚拟机线程系统的管理接口获取到线程信息，并根据所述线程信息得到线程数据，所述线程数据包括线程中的方法堆栈调用时间和CPU消耗时间；所述数据回传线程启动后创建数据回传器，每隔预定时间将所述线程数据回传给所述性能监控数据收集模块。

接收到生成CPU快照信息的控制消息后，根据所述数据采集器中的线程信息生成CPU快照文件，将所述CPU快照文件存储至预先建立的分布式文件存储装置中。

接收到生成线程快照信息的控制消息后，根据所述数据采集器中的线程信息生成线程快照文件，将所述线程快照文件存储至分布式文件存储装置中。

接收到内存数据采集的控制消息后，创建内存采集线程和内存回传线程；所述内存采集线程启动后，每隔预定时间触发预先创建的数据采集器，所述数据采集器通过应用程序编程接口获取服务器的内存信息；所述内存回传线程启动后创建数据回传器，每隔预定时间将所述内存信息回传给所述性能监控数据收集模块。

在本申请的一个实施例中，所述性能数据客户端节点模块20设置于被监控的Java服务器中，以便于监控分析Java服务器的性能数据。

所述性能监控数据收集模块30，用于收集Java服务器的性能数据并存储。

如图2所示，所述系统还包括：分布式文件存储装置40，用于存储所述CPU快照文件和/或所述线程快照文件，并将存储的文件名和链接地址返回给所述控制模块。

分布式文件存储装置40是一个高可扩展、高可用、高性能、面向互联网服务的分布式文件系统，主要针对海量的非结构化数据，它构筑在普通的Linux机器集群上，可提供高可靠和高并发的存储访问。在本申请的一个实施例中，分布式文件存储装置40可以是淘宝文件系统(TaobaoFileSystem，简称TFS)。

所述控制模块10还用于，通过所述分布式文件存储装置40获取所述CPU快照文件和/或所述线程快照文件并进行显示。

根据本申请的实施例，通过在压测的同时实时采样输出线程信息、CPU方法和内存消耗堆栈，可以把线程的所有方法输出出来，并给出自用时间的消耗和CPU时间的消耗、以及调用次数、内存使用信息。由于采用了更快更轻量级的技术，收集进程和服务器进程相互独立，互不影响，减少了性能分析对应用程序造成的影响，提高了性能分析的精度。

下面结合图3和图4详细描述本申请实施例。图3是根据本申请实施例的CPU数据分析以及生成CPU快照信息的流程图，如图3所示，包括以下步骤：

步骤S302，用户在平台上点击开始按钮，控制模块发送CPU性能分析的启动消息给性能数据客户端节点模块；

步骤S304，性能数据客户端节点模块开启一个独立的CPU分析进程，对服务器进行分析；具体地，CPU分析进程会通过Java的JMX管理接口，链接到Java服务器的Java虚拟机上，然后使用MXBeans类(用于监视和管理Java虚拟机以及Java虚拟机在其上运行的操作系统)来获取各种线程和方法的信息。在CPU分析中，用到threadInfoProvider这个类，性能数据客户端节点模块每次刷新时，都会获取所有的线程信息。ThreadInfo中，包含了线程名/方法名、线程/方法状态等信息。所有的线程/方法都会用它的名字作为key存放在一个哈希表中。如果线程/方法的状态是running(运行)的，那么就把这段时间累加到哈希表中的对应的这个线程/方法上面去。比如每隔5秒刷新一次，刷新时，发现线程A的状态是running，那么哈希表中，key为A的那条数据的值就加上5秒；同时，也通过这个ThreadInfo和状态信息来计算当前系统中各种状态下的线程数量；

步骤S306，性能数据客户端节点模块按照设定频率收集到CPU分析数据后自动回传给性能监控数据收集模块；

步骤S308，性能监控数据收集模块将收集到的数据存储至分布式文件存储装置；

步骤S310，控制模块直接获取分布式文件存储装置中存储的CPU分析数据；

步骤S312，控制模块对CPU分析数据处理后展现在页面，用户可以通过系统平台直接查看实时的收集数据，包括线程和CPU的方法消耗的统计汇总信息；

步骤S314-S316，用户可以发送停止命令，控制模块发送停止CPU分析消息给性能数据客户端节点模块，性能数据客户端节点模块停止分析进程；

步骤S318，控制模块发起生成CPU快照信息的命令给性能数据客户端节点模块；

步骤S320-S324，性能数据客户端节点模块收到命令后，获取当前采集器中的线程信息，然后根据线程信息生成CPU快照文件，将CPU快照文件上传至分布式文件存储装置，并将生成的CPU快照文件的文件名和链接地址返回给控制模块；

步骤S326，控制模块根据返回的文件名和链接地址获取存储的CPU快照文件；

步骤S328，控制模块对CPU快照信息处理后展现在页面，用户可以通过系统平台查看到收集的CPU快照信息，通过该信息可以找到详细的方法消耗，定位存在问题的服务器位置。

图4是根据本申请实施例的生成线程快照和开启内存分析的流程图，如图4所示，包括以下步骤：

步骤S402，控制模块发送开启线程快照采集信息的命令给性能数据客户端节点模块；

步骤S404-S408，性能数据客户端节点模块收到采集线程快照命令后从ThreadMXBean中Dump出线程信息，同时生成一份线程快照文件，将线程快照文件上传至分布式文件存储装置，并且把生成的线程快照文件的文件名和链接地址返回给控制模块；

步骤S410，控制模块根据返回的文件名和链接地址获取存储的线程快照文件；

步骤S412，控制模块对线程快照信息处理后展现在页面，用户可以通过系统平台查看详细的线程快照信息，通过信息可以找所有线程的名称、状态和方法堆栈，分析线程问题；

步骤S414，控制模块还可以向性能数据客户端节点模块发送开启内存分析的消息命令；

步骤S416-S418，性能数据客户端节点模块收到采集内存信息的命令后，开启内存分析过程，同时回传内存分析数据给性能监控数据收集模块。具体地，使用JDK(Java语言的软件开发工具包)中的Attach API(Sun JVM AttachAPI是Sun JVM中的一套非标准的可以连接到Java虚拟机上的API接口工具包)读取内存使用信息，并保存在一个变量中。每次刷新时，都会读取最新的内存使用信息，并更新这个变量，进行数据统计和分析。

步骤S420，性能监控数据收集模块接收到内存分析数据后入库持久化保存；

步骤S422，控制模块通过性能监控数据收集模块获取分布式文件存储装置中存储的内存分析数据；

步骤S424，控制模块对内存分析数据处理后展现在页面，用户可以通过系统平台直接查看收集的内存分析数据；

步骤S426-S428，用户可以发送停止命令，控制模块发送停止内存分析消息给性能数据客户端节点模块，性能数据客户端节点模块停止内存分析过程。

根据本申请实施例还提供一种B/S结构的性能监控分析方法。

图5示出根据本申请一个实施例的B/S结构的性能监控分析方法的流程图，参考图5，所述方法包括：

步骤S502，采用双通道消息通讯方式发送控制消息；

步骤S504，根据接收到的控制指令采集服务器的性能数据；

步骤S506，开启分析进程，对采集到的服务器的性能数据进行分析。

下面结合图6A-图6D详细描述CPU数据采集和线程采集过程。图6A是根据本申请实施例的CPU数据采集的流程图，如图6A所示，包括以下步骤：

步骤S602，接收到开启CPU数据采集命令后，创建开启数据采集的线程；

步骤S604-606，数据采集线程启动后创建一刷新器，该刷新器每隔预定的配置时间刷新，刷新时触发预先创建的数据采集器；

步骤S608-610，数据采集器通过调用Java虚拟机线程系统的管理接口获取到线程信息，并根据所述线程信息得到线程数据，所述线程数据包括线程中的方法堆栈调用时间和CPU消耗时间。具体地，通过调用Dump命令从ThreadMXBean中获取出线程信息，并对线程执行时间进行累加。

接收到停止命令后，停止开启的数据采集线程。

参考图6B，是根据本申请实施例的数据回传过程的流程图，如图6B所示，包括以下步骤：

步骤S612，接收到开启CPU数据采集命令后，创建开启数据采集的线程同时创建数据回传线程；

步骤S614，数据回传线程启动后创建一数据回传器；

步骤S616-618，每隔预定的配置时间分析和组装采集线程当中的线程数据，同时将这些线程数据统计后回传给系统监控平台。

具体地，所述线程数据主要包括线程的状态信息和方法堆栈信息。状态信息可以显示当前java服务器中所有线程的运行状态，包括Runnable运行状态(线程正在运行，或者准备好获取CPU时间后运行)、Waiting on condition(线程休眠，等待某个条件的发生)以及Waiting for monitor entry和inObject.wait()(线程在等待获取一个对象的锁，其他线程可能持有这个同步锁)等状态信息；方法堆栈信息是一个运行中的Java应用程序的所有线程的一个快照。它会显示一些像当前的堆栈跟踪、状态以及线程名称之类的信息。接收到停止命令后，停止数据回传。

参考图6C，是根据本申请实施例的生成CPU快照信息的流程图，如图6C所示，包括以下步骤：

步骤S622，接收到生成CPU快照信息的命令；

步骤S624，判断数据采集线程是否处于开启状态，如果是则通过创建的线程采集器中的线程信息生成CPU快照文件；

步骤S626，将所述CPU快照文件上传(存储)至预先建立的分布式文件存储装置(TFS)中；同时TFS将存储的CPU快照文件的文件名和链接地址返回给系统平台，用户可以通过文件名和地址查看该CPU快照信息。

参考图6D，是根据本申请实施例的生成线程快照信息的流程图，如图6D所示，包括以下步骤：

步骤S632，接收到生成线程快照信息的命令；

步骤S634，判断数据采集线程是否处于开启状态，如果是则通过创建的线程采集器中的线程信息生成线程快照文件；

步骤S636，将所述线程快照文件上传(存储)至分布式文件存储装置(TFS)中；同时分布式文件存储装置将存储的线程快照文件的文件名和链接地址返回给系统平台，用户可以通过文件名和地址查看该线程快照信息。

下面结合图7详细描述内存采集过程。

参考图7A，是根据本申请实施例的内存数据采集的流程图，如图7A所示，包括以下步骤：

步骤S702，接收到内存数据采集开启命令后，开启一内存数据采集线程；

步骤S704-706，内存采集线程启动后创建一刷新器，该刷新器每隔预定的配置时间刷新，刷新时触发预先创建的数据采集器；

步骤S708-710，所述数据采集器通过应用程序编程接口(API)获取Java服务器的内存信息；

接收到停止命令后，停止开启的内存采集线程。

参考图7B，是根据本申请实施例的内存数据回传的流程图，如图7B所示，包括以下步骤：

步骤S712，接收到开启CPU数据采集命令后，创建开启内存数据采集的线程同时创建内存数据回传线程；

步骤S714，内存数据回传线程启动后创建一数据回传器；

步骤S716-718，每隔预定时间将所述内存信息回传给所述性能监控数据收集模块。接收到停止命令后，停止内存数据回传。

下面结合表1描述本申请实施例的性能分析过程。

表1

通过以上开启的分析过程，可以将服务器执行的线程信息和CPU消耗信息根据采样的方式输出出来：在CPU分析中，将所有的线程/方法的名字作为key存放在一个哈希表中，如果线程/方法的状态是running(运行)的，那么就把这段时间累加到哈希表中的对应的这个线程/方法上面去。比如每隔5秒刷新一次，刷新时，发现线程A的状态是running，那么哈希表中，key为A的那条数据的值就加上5秒。

根据表1所示，根据Dump出来的线程信息只有B为running(运行)状态，其他线程都是wait(等待)状态，那么就可以分析出线程在等待什么、是否有锁等待等等，从而分析出性能瓶颈所在。

通过更新出的线程信息，发现在A、B、C三个线程中B的执行时间最长，同时B的CPU消耗时间也最大，从而分析出B是需要优化的线程。

同时也可以根据快照信息，将B线程的所有方法递归进去查询，最后发现是哪个方法占用B的时间(20秒)最长，同时也可以分析出来是哪个方法占用B的CPU时间(15秒)最多；一般消耗时间最长的，不一定消耗CPU，如远程调用，所以从消耗时间和CPU时间上共同寻找出问题所在，重点优化。

本申请的方法的操作步骤与装置的结构特征对应，可以相互参照，不再一一赘述。

综上所述，本申请具备以下优点：

(1)B/S结构。用户可以在任何时间任何地点，打开平台，执行、停止和查看监控数据。

(2)无侵入式的。服务器不需要埋点，不需要写代码，利用JMX的统一管理框架。

(3)全方法堆栈的。从调用方法开始，一直到最后的远程调用或数据库调用，全部呈现在用户面前，这样做的好处是：a.用户事先不需要知道调用的方法，不需要输入任何信息，方法自动会呈现在用户面前；b.可以通过这个堆栈分析用户的调用路径是否正确，是否存在不该走的方法，是否走的缓存等。

(4)数据持久化保存在数据库和云端，和每次压测结果放在一起，用户可以随时打开，也可以给开发或者其他测试者查看使用和分享。

(5)采样分析对进程资源消耗非常低(大约1％)，可用于线上分析。同时采用的开启和关闭都可以在系统平台上实时操作。

(6)过滤器设置。采样的同时也可以根据用户定义的包或者方法规则，过滤出用户需要监控的内容，减小额外开销。

(7)性能数据客户端节点进程和服务器进程独立，相互之间不影响。

(8)消息控制采用双通道。一方面通过Socket监听，另一方面可以通过MQ消息监听，这样可以实现跨各种网络环境的监控操作和数据采集。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

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

Claims (20)

1.一种B/S结构的性能监控分析系统，用于监控分析Java服务器的性能数据，其特征在于，所述系统包括：控制模块、性能数据客户端节点模块、性能监控数据收集模块；

所述控制模块，用于采用双通道消息通讯方式向所述性能数据客户端节点模块发送控制消息；

所述性能数据客户端节点模块，用于根据接收到的控制消息采集Java服务器的性能数据；

所述性能监控数据收集模块，用于收集Java服务器的性能数据并存储。

2.根据权利要求1所述的系统，其特征在于，所述性能数据客户端节点模块还用于，接收到CPU数据采集的控制消息，创建数据采集线程和数据回传线程，通过所述数据采集线程采集服务器的性能数据，并通过所述数据回传线程将采集到的性能数据传送至所述性能监控数据收集模块。

3.根据权利要求2所述的系统，其特征在于，所述性能数据客户端节点模块还用于，所述数据采集线程启动后，每隔预定时间触发预先创建的数据采集器，所述数据采集器通过调用Java虚拟机线程系统的管理接口获取到线程信息，并根据所述线程信息得到线程数据，所述线程数据包括线程中的方法堆栈调用时间和CPU消耗时间。

4.根据权利要求3所述的系统，其特征在于，所述性能数据客户端节点模块还用于，所述数据回传线程启动后创建数据回传器，每隔预定时间将所述线程数据回传给所述性能监控数据收集模块。

5.根据权利要求3所述的系统，其特征在于，所述性能数据客户端节点模块还用于，接收到生成CPU快照信息的控制消息，根据所述数据采集器中的线程信息生成CPU快照文件，将所述CPU快照文件存储至预先建立的分布式文件存储装置中。

6.根据权利要求3所述的系统，其特征在于，所述性能数据客户端节点模块还用于，接收到生成线程快照信息的控制消息，根据所述数据采集器中的线程信息生成线程快照文件，将所述线程快照文件存储至分布式文件存储装置中。

7.根据权利要求5或6所述的系统，其特征在于，还包括：

分布式文件存储装置，用于存储所述CPU快照文件和/或所述线程快照文件，并将存储的文件的文件名和链接地址返回给所述控制模块。

8.根据权利要求7所述的系统，其特征在于，所述控制模块还用于，通过所述分布式文件存储装置获取所述CPU快照文件和/或所述线程快照文件并进行显示。

9.根据权利要求1所述的系统，其特征在于，所述性能数据客户端节点模块还用于，接收到内存数据采集的控制消息，创建内存采集线程和内存回传线程；所述内存采集线程启动后，每隔预定时间触发预先创建的数据采集器，所述数据采集器通过应用程序编程接口获取服务器的内存信息；所述内存回传线程启动后创建数据回传器，每隔预定时间将所述内存信息回传给所述性能监控数据收集模块。

10.根据权利要求1至9中任一项所述的系统，其特征在于，所述性能数据客户端节点模块设置于Java服务器中。

11.根据权利要求1至9中任一项所述的系统，其特征在于，所述双通道消息通讯方式包括：套接字消息通讯方式、消息队列通讯方式。

12.一种B/S结构的性能监控分析方法，用于监控分析Java服务器的性能数据，其特征在于，所述方法包括：

采用双通道消息通讯方式发送控制消息；

根据接收到的控制消息采集Java服务器的性能数据；

收集Java服务器的性能数据并存储。

13.根据权利要求12所述的方法，其特征在于，还包括：

接收到CPU数据采集的控制消息，创建数据采集线程和数据回传线程，通过所述数据采集线程采集服务器的性能数据，并通过所述数据回传线程回传采集到的性能数据。

14.根据权利要求13所述的方法，其特征在于，还包括：

所述数据采集线程启动后，每隔预定时间触发预先创建的数据采集器，所述数据采集器通过调用Java虚拟机线程系统的管理接口获取到线程信息，并根据所述线程信息得到线程数据，所述线程数据包括线程中的方法堆栈调用时间和CPU消耗时间。

15.根据权利要求14所述的方法，其特征在于，还包括：

所述数据回传线程启动后创建数据回传器，每隔预定时间回传所述线程数据。

16.根据权利要求14所述的方法，其特征在于，还包括：

接收到生成CPU快照信息的控制消息，根据所述数据采集器中的线程信息生成CPU快照文件，将所述CPU快照文件进行存储。

17.根据权利要求14所述的方法，其特征在于，还包括：

接收到生成线程快照信息的控制消息，根据所述数据采集器中的线程信息并生成线程快照文件，将所述线程快照文件进行存储。

18.根据权利要求14所述的方法，其特征在于，获取所述CPU快照文件和/或所述线程快照文件并进行显示。

19.根据权利要求12所述的方法，其特征在于，还包括：

接收到内存数据采集的控制消息，创建内存采集线程和内存回传线程；

所述内存采集线程启动后，每隔预定时间触发预先创建的数据采集器，所述数据采集器通过应用程序编程接口获取服务器的内存信息；

所述内存回传线程启动后创建数据回传器，每隔预定时间回传所述内存信息。

20.根据权利要求12至19中任一项所述的方法，其特征在于，所述双通道消息通讯方式包括：套接字消息通讯方式、消息队列通讯方式。