多层散布式系统的瓶颈检测方式_第1页
多层散布式系统的瓶颈检测方式_第2页
多层散布式系统的瓶颈检测方式_第3页
多层散布式系统的瓶颈检测方式_第4页
多层散布式系统的瓶颈检测方式_第5页
已阅读5页,还剩14页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、第1章多层散布式系统的瓶颈检测方式概述系统性能指标可分为系统级性能指标(CPU内存和网络等利用率)和应用程序级性能指标(平均反映时刻SIRT和吞吐量SIPS等)两大部份。所有的这些系统资源都可能致使系统知足不了用户SLO的中意度,系统分析员和治理员的职责是监控和分析大量的系统性能指标,分析瓶颈产生的缘故,并最终通过添加正确的硬件以达到提高系统性能的目的。现在,对多层架构系统的瓶颈检测乃至比开发系统本身还重要,也是实现系统能力计划的重要一步。本章将研究多层散布式架构系统的瓶颈检测方式,其组织结构如下:第2节描述瓶颈检测方式;第3节对第2节提出的瓶颈检测方式进行实验评估;第4节介绍瓶颈检测进程所涉

2、及的几个关键技术;第5节对本章进行小结。瓶颈检测方式描述机械学习在科研和商业应用中正发挥着愈来愈重要的作用。分类器是机械学习的一种大体方式,决策树又是一种最重要的分类器。在本节,咱们提出了一种基于决策树的系统瓶颈检测方式,并采纳ID3分类算法对决策树进行分类。宏观上给出了系统瓶颈检测的三大步骤;详细描述决策树ID3分类算法,包括其算法流程及信息熵、条件熵、信息增量的计算。瓶颈检测的一样步骤瓶颈检测需要借助于系统实时性能数据的分析,而这些数据是在一系列处于不同负载压力的实验中得出。一开始系统处于低负载压力的情形下,但随实在验的进行,负载压力会不断增大,直到系统达到瓶颈为止。例如,实验以10个并发

3、的EBs开始,每次增加10个EBs,直至系统的吞吐量急剧下降(即系统显现瓶颈)为止。搜集到所需的性能数据以后,即能够依照以下三个步骤来检测系统瓶颈:第一步:判定当前系统是不是已处于瓶颈状态;概念3-1SLA效劳水平协议(简称:SLA全称:ServiceLevelAgreement:)是指在必然开销下为保障效劳的性能和靠得住性,效劳提供商与用户间概念的一种两边认可的协定。概念3-2SLO效劳水平目标(简称:SLQ全称:ServiceLevelObject)是指一个或多个有限定的效劳组件测量的组合,一样来讲,SLA的保障是以一系列效劳水平目标(SLO的形式概念。效劳水平目标(SLO中意度是衡量系统

4、是不是知足客户需求最好的评判标准,一样以为当SLO中意度小于某一百分比(如75%时,能够为系统已无法知足一样用户需求,即可判定现在系统显现瓶颈。SLO中意度由SLO评估器通过必然算法生成,但针对不同的系统和用户需求,SLO中意度的求解方式不尽相同。为了实验方便,咱们的SLO中意度采纳以下公式求得:SLO满意度当前的S1Ps100%符合用户最大需求的SIPS00%其中SIPS是指每秒钟Web效劳的交互数,它是衡量系统性能最重要的一个指标(详见),当前的SIPS是指在当前用户访问量的情形下,系统每秒钟能处置的Weba劳交互数,它的值等于SIRT平均值的倒数:系统当前的SIPS1当前SIRT平均值当

5、前SIRT平均值是指系统Webt劳的平均响应时刻(详见),TPC-Ap洲准包括7个Weba劳(详见),每一个Webt劳的SIRT都可由实时监控工具统计,故计算公式如下:7当前SIRT平均值SIR7(3.3)其中SIPSi(1i7)是指第i种Weba劳的平均响应时刻符合用户最大需求的SIPS概念为一常量,在本文中,咱们设定为100,即用户对系统的最高要求是系统每秒钟能达到100个Web劳交互数。第二步:判定瓶颈出此刻多层架构中的哪一层;概念3-3瓶颈层:在多层散布式架构中,致使系统最先显现瓶颈的层称之为瓶颈层。在第一步中,假设判定当前系统已处于瓶颈状态,接着需要判定系统哪一层先显现瓶颈。当前大型

6、的IT企业应用一样包括三层,它们别离是HTTP层、应用层和数据层,因此一次Webt劳的总响应时刻等于HTTPS执行时亥人应用层执行时刻和数据层执行时刻之和。瓶颈层的特点是随着负载压力的不断增大,其执行时刻的增加速度最快。第三步:判定瓶颈层的哪些资源致使瓶颈。概念3-4瓶颈资源:在多层散布式架构中,瓶颈层中致使系统瓶颈的系统资源称之为瓶颈资源。系统的资源要紧包括CPU内存、网络带宽等,咱们把致使系统瓶颈的资源称之为瓶颈资源,把不是致使系统瓶颈的资源称之为非瓶颈资源。瓶颈资源具有以下三个要紧特点:1)高利用率;具有高利用率的资源意味着应用程序对它有高需求,是一个潜在的瓶颈资源。一样来讲,只有利用率

7、超过某一界限(如85%)才可能是瓶颈资源。2)增加率从某一正数慢慢接近于零;随着负载压力的慢慢增大,该资源的利用率也随之增加,当增加率接近于零时表示现在该资源的利用率已达极限。3)SLO中意度的大小与该资源利用率的高低关系紧密。在该资源处于低利用率的情形下,加大负载压力,SLO中意度会慢慢上升;在该资源处于高利用率的情形下,加大负载压力,SLO中意度会急剧下降。1.2.2决策树ID3分类算法在上一节第三步中提到的系统资源与SLO中意度的关系能够采纳机械学习中的决策树ID3分类算法来量化判定。由于决策树的结构越简单越能从本质上归纳事物的规律,即生成的决策树的平均深度最小,因此这就要求对各个结点选

8、择最优划分。在各类决策树分类的算法中,初期的有CAR存习算法和CLS算法,而最具阻碍力的是Quinlan提出的ID3算法,该算法的最终目标是要生成一棵输出决策树,对应的输出是大量的类别实例。它的具体步骤如下:检查所有的属性,选择信息增益最大的属性作为决策树结点,由该属性的不同取值成立分支,再对各分支的子结点递归挪用以上步骤直至所有子集仅包括同一类别的数据为止。最后便取得一棵对新样本进行分类的决策树。阻碍运算机系统性能的系统资源很多,在数据挖掘初期,咱们不明白哪些是要紧因素,更不明白各个因素阻碍因子的大小。因此,咱们把因此可能致使系统瓶颈的资源都考虑进来,如CPU内存、网络带宽等。决策树的内部结

9、点信息记录系统资源利用率的增加幅度(即增加率),而叶结点包括所有SLO中意度的大小。通过检查生成的决策树,咱们能够找出和SLO中意度关系最紧密的系统资源。若是生成的决策树中包括多种资源,那么在内部结点中显现次数最多的资源被以为是最有可能致使系统瓶颈的资源。算法描述咱们第一提出决策树的概念:概念3-5决策树:决策树是用二叉树形图来表示处置逻辑的一种工具。能够直观、清楚地表达加工的逻辑要求。专门适合于判定因素比较少、逻辑组合关系不复杂的情形。一棵决策树可表示为DT(S,A),其中S是训练样本集,A是候选属性集,表示为A=A1,A2,A3,Am,并假设最终将训练样本集分成N类。基于概念3-1,决策树

10、ID3分类算法执行流程如下:A为空?返回i作为叶节 点,并以类C标识返回i作为叶节 点,标识为普通类创建节点i选A中最高消息增益的属性TestA,标识节点i为TestATestA中还存在,未被选的值?从TestA中选择a由节点i长出MaxA=a的分支S中TestA=a的样本加上一树叶,标识为普通类集合T为空?/加入一个由DT(T,A-TestA)返回的节点图1-1决策树ID3分类算法流程图信息嫡的计算设第i(i=i=N)类的训练样本个数为|S|,假设记一个实例属于第i类的概率为P(Si),那么有:|SiP网现在,信息嫡的概念如下:mEntropy(S)(P(S)log2P()i13.3条件嫡的

11、计算子结点不纯性程度的大小事选择最正确划分气宇的依据,子结点越不纯,类的划分在决策树上就越倾斜。假设选择测试属性A进行测试,设A具有属性项(a1,a2,.,ak),在A=aj的情形下属于第i类的实例个数为Cij个,实例个数为Yi。用P(Si|Aaj)表示测试属性A的取值为j时,属于第i类决策的概率,其计算公式如下:P(Si|A aj)宜YiEntropy (S, A aj)由前面的公式(3.4)、(3.5)和(3.6)能够得出决策树对分类的不确信程度,即训练样本实例集对属性A的条件嫡为:(p(Si|Aaj)log2P(Si|Aaj)(3.7)在选择测试属性A后,每一个Aaj叶结点Yj关于分类信

12、息的信息嫡为:B(S,A)(P(Si|Aaj)Entropy(S,Aaj)3.4条件嫡的计算有前面的公式(3.5)和(3.8)可知,属性A对类别划分提供的信息量,即属性A的信息增益为:Gain(S,A)Entropy(S)B(S,A)(p(Si|Aaj)10g2P(Si|Aaj)(P(S|Aaj)Entropy(S,Aaj)通过比较所有属性的信息增益,取其中最大值对应的测试属性作为类别划分的依据,构造一级决策树。然后继续用一样的方式不断递归处置,慢慢求精,能够构造二级和多级决策树,直抵达到分类目标,生成所有叶结点。1.3瓶颈检测的实验评估在上节中,咱们提出了多层架构系统瓶颈检测的三大步骤,并采

13、纳机械学习的方式,提出了决策树ID3分类算法。在本节中,咱们将利用由第二章实现的基于TPC-App基准的测试系统来评估上节中提出的瓶颈检测方式。第一,咱们在中给出了实验软硬件环境的配置情形;接着,咱们在中依照节中提出的三大步骤对被测系统进行瓶颈检测;然后,咱们在中以实验评估的方式对中得出的瓶颈层和瓶颈资源进行验证;最后,在中,咱们对基于TPC-App基准的被测系统性能进行整体分析,以实现对系统的能力计划。实验软硬件环境本实验的软件环境配置如下:Apache作为HTT吸劳器;JBoss作为应用效劳器;MySQ昨为数据库效劳器;ApacheTomcat作为外部Web:劳模拟器;Apachemod_

14、jk模块作为负载均衡器;nmon作为系统性能数据实时统计工具,ApacheAxis2作为开发We做劳的辅助工具。为了保证明验结果的真实性、靠得住性和可再现性,咱们尽可能维持软件的默许配置,除以下两点:1)关于JBoss,咱们加大了We欣劳的最大连接数(调至1024),并用all模式启动以支持散布式环境;2)关于MySQL咱们加大了用户最大并发数(调至1000)以支持高负载情形下数据库的正常连接。表3-1列出了本实验中所利用的软件清单。TPC-App基准规定的测试系统至少需要有三台机械:一台HTTP效劳器、一台应用效劳器和一台数据库效劳器。其中Apache和mod_jk部署在HTT瓒劳器上,JB

15、oss和Tomcat部署在应用效劳器上,MySQIf口Amoeba署在数据库效劳器上,且所有软件都运行在RedhatLinux系统上。其中HTT瓒劳器的低性能配置为PentiumHz双核、1GB内存,高性能配置为PentiumHz双核、2GB内存;应用效劳器的低性能配置为:XeonHz双核、2GB内存,高性能配置为XeonHzM核、4GB内存;数据库效劳器的低性能配置为:Xeon2.5GHz四核、4GB内存,高性能配置为XeonHz双核、6GB内存。表3-2列出了本实验中所利用的硬件清单。表1-1实验软件配置清单软件名称版本号功能描述配置Redhat操作系统软件默认配置ApacheHTTP服务

16、器,提供用户操作界面。默认配置mod_jk/负载均衡器,用于平均分发HTTP青求。默认配置JBossGAJ2EE应用服务器,用于部署TPC-App基准规定的7个Web服务。加大Web服务最大连接数至1024,以all模式启动Tomcat轻量级应用服务器,用于部署TPC-App基准规定的4个外部Web服务。默认配置MySQLMax数据库服务器,用于部署TPC-App基准规定的8个数据库表。加大用户最大并发数至1000AmoebaforMySLQ分布式数据库代理,附于更好的解决数据库集群部署。默认配置nmon530实时统计Linux系统的各项性能指标。记录时间间隔设为1sAxis2新一代SOA用擎

17、,方便Web服务的访问和部署。默认配置表1-2实验硬件配置清单HTTP服务器应用服务器数据库服务器性能低性能(L)高性能(H)低性能(L)高性能(H低性能(L)高性能(H)CPUPentium双核Pentium双核Xeon四核Xeon四核Xeon四核Xeon四核内存1G2G2G4G3G6G硬盘320GB500GB146GB200GB146GB200GB单价30005000700015000900018000数量121213131212瓶颈检测进程实验的初始硬件配置为1/1/1(即1台HTTP效劳器、1台应用效劳器和1台数据库效劳器)。客户并发数EBs从10开始,下一次EBs比上一次增加10,每

18、次都实时记录SIRT和SIPS,从而计算出SLO中意度。图3-2显示了随着EBs的不断增大,SLO中意度的转变示用意。从图中咱们能够看出在1/1/1的硬件环境下,当EBs较小时,SLO中意度随着EBs的增加而慢慢增大;当EBs大于100时,SLO中意度再也不随着EBs的增加而增大,而是维持较为稳固的状态;但当EBs大于180时,SLO中意度大幅度下降。因此,咱们能够判定当EBs大于等于180时,系统已显现瓶颈。0123上LHICRILLLLL112222ODODOOQOO口y2S4/67OS9O1l-w5qqaa。a。a。aqo0qE05图1-2SLO中意度转变示用意接着咱们需要判定三层中哪一

19、层最先显现瓶颈,即瓶颈层在哪一层。图3-3显示了在配置为1/1/1的情形下对TPC-App#准测试的总响应时刻及其各层的执行时刻的统计。从图中咱们能够看出HTTP层的执行时刻最少,不到总响应时刻5%且其转变率几乎为零,因此可先排除HTTPS;数据层的执行时刻尽管在客户访问量小的时候比应用层高,但随着访问量的增加,它占总响应时刻的比例愈来愈小,且其增加率是一个很小的常数,因此数据层也不太可能是瓶颈层;应用层的执行时刻随着客户访问量的增加而不断增加,增加速度在三层中最快,且其占总响应时刻的比例愈来愈大。因此在本例中可判定应用层是致使Web:劳响应时刻变慢的要紧缘故,即应用层是瓶颈层。图1-3总响应

20、时刻及各层执行时刻转变示用意一旦判定瓶颈出此刻应用层后,咱们便开始对应用层的系统资源进行分析,以确信哪些系统资源是瓶颈资源。图3-4和图3-5别离显示了应用效劳器中三个典型的系统资源(CPU内存、网络带宽)利用率和转变率示用意。观测这两个图,第一可排除网络带宽,因为它的利用率一直很小,未抵达85%勺临界限。第二可排除内存,因为尽管它的利用率很高(超过85%,但其转变率几乎为零。最后咱们得出CPUa瓶颈资源,因为它都一一知足了瓶颈资源的三个条件:1)高利用率。从图3-4中能够看出当EBs大于150时,CPUP用率超过85%缶界限;2)增加率从某一正数慢慢接近于零。从图3-5中能够看出随着EBs的

21、增加,CPU利用率的增加量从某一正数慢慢缩小至零;3)CPU利用率的大小阻碍着SLO中意度的高低。当CPU利用率低时,随着负载压力的增大,SLO中意度慢慢上升;当CPUffl用率高时,随着负载压力的增大,SLO中意度急剧下降。综上所述,咱们可得出CPUa瓶颈资源的结论。图1-4应用层系统资源利用率示用意13-z变化率SO%-10%-206图1-5应用层系统资源转变率示用意以上是采纳较为直观的观看方式得出CPU瓶颈资源的结论,为了得出更科学的结论,下面咱们将采纳提出的ID3分类方式构造出决策树。从图3-5中,咱们明白CPUI勺转变率从某一正数(19流右)慢慢接近于0%而内存和网络带宽的转变率几乎

22、一直为0%把这些数据作为ID3分类器的输入,咱们即可构造出图3-6所示的决策树。从图中咱们能够看出SLO中意度的高低和CPU?专变率的大小有直接的关系,而和内存、网络带宽的转变率没有关系。因此,咱们也可判定出CPU瓶颈资源。图1-6应用层各系统资源与SLO中意度的决策树瓶颈检测实验结果验证在上一节中,咱们通过提出的瓶颈检测方式,得出在1/1/1的配置下,系统的瓶颈出此刻应用层,且应用层的CPU致使系统显现瓶颈的资源。为了客观验证上述判定的准确性,在这一节中,咱们将通过实验的方式对瓶颈检测结果进行验证。第一,为了验证瓶颈确实出此刻应用层,咱们在原有的1/1/1配置基础上别离增加1台HTT瓒劳器、

23、1台应用效劳器和1台数据库效劳器,即配置别离为2/1/1、1/2/1和1/1/2。图3-7显示了在这四种配置下得出的系统性能数据比较(在那个地址,咱们以TPC-App基准中规定的SIPS,即每秒钟We欣劳交互数,作为衡量系统性能高低的唯一标准)。从图中咱们能够看出增加1台HTT瓒劳器对性能几乎没有提升,增加1台数据库效劳器对性能尽管有所提升,但并非明显,只提升了10流右,而增加1台应用效劳器对系统性能有明显的提升,大约是原系统的两倍。如此便证明了在原系统中,最先显现瓶颈的确实是应用层。图1-7各层不同配置下系统性能比较接着咱们增加应用效劳器中CPU内存、网络的供给量,其中CPU+俵示CPU的主

24、频增加,CPU+2ft示CPUi频增加1GHz内存+1表示内存容量增加1GB内存+2表示内容容量增加2GB网络+1表示网络带宽增加10M网络+2表示网络带宽20M图3-8别离显示了上述的6种配置与标准配置系统性能的比较。从图中咱们能够看出增加CP频对系统性能有较为明显地提升,增加内存容量对系统性能有些许地提升,而增加网络带宽对系统性能几乎没有阻碍。因此,证明了应用层中的CPU瓶颈资源。图1-8应用层不同资源配置下系统性能比较实验结果整体分析图3-9显示了在不同硬件配置条件下,对TPC-App基准测试得出的SLO两意度。从图中咱们能够得出以下几个重要结论:HTTP层一样可不能成为瓶颈层:H/H/

25、H与L/H/H的SLO中意度几乎相同,可见增加一台HTTP应用效劳器对被测系统的整体性能几乎没有提升。2)在初始时期,应用层是瓶颈层,但随着应用效劳器数量的增加,数据层变成瓶颈层:在初始配置L/L/L的情形下,增加一台应用效劳器(L/2L/L)或把原应用效劳器换成高性能机械(L/H/L),被测系统的SLO中意度有显著提高(变成原先的两倍多),而把数据库效劳器换成高性能机械(L/H/H)对SLO中意度没有阻碍。但当应用效劳器足够时(如L/2L/L),增加一台数据库效劳器(L/2L/2L)比增加一台应用效劳器(L/3L/L)对SLO中意度的提升更多。3)集群比单结点性价比高:最后咱们还发觉L/2L

26、/L(14000)比L/H/L(15000)花费更少,却能取得更高的SLO中意度,因此假设了解此特性,便能有效地节约本钱。图1-9TPC-App性能实验评估结果瓶颈检测的关键技术以上几节介绍了多层架构系统瓶颈检测的实验进程,本节咱们将论述该实验所涉及的几个关键技术。咱们将在中介绍如何利用LoadRunner模拟真实的负载,以保证明验结果的真实靠得住性;在中介绍如何从原始数据中准确提取所需的那部份数据;在中介绍如何快速地处置与分析海量的实验数据。系统真实负载的模拟利用LoadRunner的虚拟发生器(VirtualGenerator),测试者能够轻松创建虚拟用户,模拟真实的业务流程和用户操作行为

27、。借助参数化的功能实现并发用户的不同行为,进而实现真正意义上的并发。通过TurboLoad专利技术,更能让客户取得最高的规模适应性水平。LoadRunner要紧包括5大组件,它们或作为独立的模块别离完成各自功能,或作为LoadRunner的一部份彼此衔接,与其他模块一起完成系统性能的整体测试。这5大组件别离是:VirtualGenerator(虚拟生成器),用于捕捉实际用户业务流程和创建自动性能测试脚本;Controller(操纵器),用于组织、驱动、治理和监控负载测试;LoadGenerator(负载生成器),通过运行虚拟用户生成负载;Analysis(分析组件),用于查看、分析和比较性能测

28、试结果;Launcher(启动组件),为执行LoadRunner各项任务提供统一界面。图3-10显示了LoadRunner的工作原理。虚拟生成器通过录制客户端和后台效劳器之间的通信包,分析其中的协议,自动产生脚本。客户在自动产生脚本的基础上进行修改,从而快速开发出一个逻辑功能和客户端软件完全一样的压力脚本程序。创建虚拟用户后,便开始设定负载方案,业务流程组合和虚拟用户数量。操纵器的Rendezvous功能提供一个互动的环境,在其中既能成立起持续循环的负载,又能治理和驱动负载测试方案。而且,还能够利用它的日程打算效劳来概念用户在何时访问系统以产生负载。最后,分析组件通过对操纵器搜集的大量数据进行

29、综合分析,以图的形式展现给用户,用户通过度析各类参数指标来确信系统的性能瓶颈所在。客户图1-10LoadRunner工作原理示用意数据库服务器海量数据的分析与处置在数据搜集系统测试中,除要对测量值及其各类处置后的数据进行记录外,还要对此系统所测得的原始数据进行存储以便往后分析和统计。因此,在测试软件的界面上应该能够同时显示出处置后的数据和原始数据以便在测试后马上能够查看与该记录相关的所有数据。咱们的解决方案是在测试时只在后台向ACCES激据库的原始数据表中添加记录但不在界面上显示这些数据。当需要查看原始数据时,在处置后数据表所对应的List控件当选择所对应的那条记录,掏出其索引值,然后在原始数

30、据表中查找与该索引值相匹配的假设干条原始数字量数据,把它们提掏出来在另一个List控件中显示。如此显示原始数据时只相当于对假设干条记录进行显示,这种情形完全属于小数据量情形,因此速度专门快。同时能够对这假设干条数据进行比较,找出最大和最小值,并在该List控件中向这些记录添加标志,如此即能够完成数据极值的标志添加功能,又节省了数据库中存储标志值的空间。关于上一段中提到的数据库中的数据,需要以数据库文件(*mdb)的形式进行存储,以方便下一次继续进行测量时能够打开该数据库文件,并向该数据库文件中添加或删除记录。为了使该测试软件的界面更为友好,需要把数据库的数据与界面的显示同步起来。一种很显然的做

31、法是在应用程序每次打开一个数据库文件时把数据库中的数据全数加载到界面上的List控件中,如此做能够保证在List控件中添加和删除数据与在数据库中的操作完全同步。可是当数据库文件达到数百兆以上时,向List控件中加载海量数据会致使数据库文件打开进程超级缓慢。咱们的解决方案是引入滑动窗口机制。当打开一个海量数据库文件时仅仅把该数据库中一部份数据量提掏出来,然后将它们添加到界面的List控件中。如此做就能够够幸免在打开或初始化程序时把全数海量数据添加进来所带来的打开速度过慢问题。在程序的运行进程中,应该能够方便的在界面上查看和处置数据库中的记录,因此需要为窗口提供翻页和定位功能并始终维持显示窗口与数据库相应位置的同步。同步是滑动窗口机制可否顺利运转的关键。需要把ACCES数据库的记录指针和List控件的Item指针绑定起来,在窗口翻页或更新定位时依照List控件的Item指针查找数据库中的记录指针,然后依照该指针在ACCES漱据库中提取必然的数据并把它们更新到List控件中。如此用户就能够够方便的在List控件中查看他需要的数据。在每次用户定位后,当即从数据库中提取

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论