【IT168 技术文档】1.前言:
LoadRunner 最重要也是最难理解的地方--测试结果的分析.其余的录制和加压测试等设置对于我们来讲通过几次操作就可以轻松掌握了.针对 Results Analysis 我用图片加文字做了一个例子,希望通过例子能给大家更多的帮助.这个例子主要讲述的是多个用户同时接管任务,测试系统的响应能力,确定系统瓶颈所在.客户要求响应时间是1 个人接管的时间在5S 内.
2.系统资源:
2.1 硬件环境：
CPU：奔四2.8E
硬盘：100G
网络环境：100Mbps
2.2 软件环境：
操作系统：英文windowsXP
服务器：tomcat 服务
浏览器：IE6.0
系统结构：B/S 结构
3.添加监视资源
下面要讲述的例子添加了我们平常测试中最常用到的一些资源参数.另外有些特殊的资源暂时在这里不做讲解了.我会在以后相继补充进来。
Mercury LoadrunnerAnalysis 中最常用的5 种资源.
1. Vuser
2. Transactions
3. Web Resources
4. Web PageBreakdown
5. System Resources
在Analysis 中选择“Add graph”或“New graph”就可以看到这几个资源了.还有其他没有数据的资源,我们没有让它显示.
如果想查看更多的资源,可以将左下角的display only graphs containing data 置为不选.然后选中相应的点“open graph”即可.
打开Analysis 首先可以看的是Summary Report.这里显示了测试的分析摘要.应有尽有.但是我们并不需要每个都要仔细去看.下面介绍一下部分的含义：
Duration(持续时间)：了解该测试过程持续时间.测试人员本身要对这个时期内系统一共做了多少的事有大致的熟悉了解.以确定下次增加更多的任务条件下测试的持续时间。
Statistics Summary(统计摘要)：只是大概了解一下测试数据,对我们具体分析没有太大的作用.
Transaction Summary(事务摘要)：了解平均响应时间Average单位为秒.
其余的看不看都可以.都不是很重要.
【注】 51Testing授权IT168独家转载，未经明确的书面许可，任何人或单位不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
内容导航
4.分析集合点
在录制脚本中通常我们会使用到集合点,那么既然我们用到了集合点,我们就需要知道Vuser 是在什么时候集合在这个点上,又是怎样的一个被释放的过程.这个时候就需要观察Vuser-Rendezvous 图.
图1
可以看到大概在3 分50 的地方30 个用户才全部集中到start 集合点,持续了3 分多,在7 分30 的位置开始释放用户,9 分30 还有18 个用户,11 分10 还有5 个用户,整个过程持续了12 分.
图2
上面图2 是集合点与平均事务响应时间的比较图.
注:在打开analysis 之后系统LR 默认这两个曲线是不在同一张图中的.这就需要自行设置了.具体步骤如下:
点击图上.右键选择merge graphs.然后在select graph tomerge with 中选择即将用来进行比较的graph.如图3:
图3
图2 中较深颜色的是平均响应时间,浅色的为集合点,当Vuser 在集合点持续了1分后平均响应时间呈现最大值,可见用户的并发对系统的性能是一个很大的考验.接下来看一下与事务有关的参数分析.下看一张图.
图4
这张图包括AverageTransaction Response Time 和Running Vuser 两个数据图.从图中可以看到Vuser_init_Transaction(系统登录)对系统无任何的影响,Vuser 达到15 个的时候平均事务响应时间才有明显的升高,也就是说系统达到最优性能的时候允许14 个用户同时处理事务,Vuser 达到30 后1 分,系统响应时间最大,那么这个最大响应时间是要推迟1 分钟才出现的,在系统稳定之后事务响应时间开始下降说明这个时候有些用户已经执行完了操作.同时也可以看出要想将事务响应时间控制在10S 内.Vuser 数量最多不能超过2 个.看来是很难满足用户的需求了.
做一件事有时候上级会问你这件事办得怎么样了.你会说做完一半了.那么这个一半的事情你花了多少时间呢?所以我们要想知道在给定时间的范围内完成事务的百分比就要靠下面这个图(Transaction Response Time(Percentile)
图中画圈的地方表示10%的事务的响应时间是在80S 左右.80S 对于用户来说不是一个很小的数字,而且只有10%的事务,汗.你觉得这个系统性能会好么!
实际工作中遇到的事情不是每一件事都能够在很短的时间内完成的,对于那些需要时间的事情我们就要分配适当的时间处理,时间分配的不均匀就会出现有些事情消耗的时间长一些,有些事情消耗的短一些,但我们自己清楚.LR 同样也为我们提供了这样的功能,使我们可以了解大部分的事务响应时间是多少?以确定这个系统我们还要付出多少的代价来提高它.
Transaction Response Time(Distribution)-事务响应时间(分布)
显示在方案中执行事务所用时间的分布.如果定义了可以接受的最小和最大事务性能时间,可以通过此图确定服务器性能是否在可接受范围内.
很明显大多数事务的响应时间在60-140S.在我测试过的项目中多数客户所能接受的最大响应时间也要在20S 左右.140S 的时间!很少有人会去花这么多的时间去等待页面的出现吧!
通过观察以上的数据表.我们不难看到此系统在这种环境下并不理想.世间事有果就有因,那么是什么原因导致得系统性能这样差呢?让我们一步一步的分析.
系统性能不好的原因多方面,我们先从应用程序看.有的时候我不得不承认LR 的功能真的很强大,这也是我喜欢它的原因.先看一张页面细分图.
一个应用程序是由很多个组件组成的,整个系统性能不好那我们就把它彻底的剖析一下.图片中显示了整个测试过程中涉及到的所有web 页.web page breakdown中显示的是每个页面的下载时间.点选左下角web page breakdown 展开,可以看到每个页中包括的css 样式表,js 脚本,jsp 页面等所有的属性.
在select page tobreakdown 中选择页面.
见图.
在 Select Page To Breakdown 中选择http://192.168.0.135:8888/usertasks 后,在下方看到属于它的两个组件,第一行中Connection和FirstBuffer 占据了整个的时间,那么它的消耗时间点就在这里,我们解决问题就要从这里下手.
也有可能你的程序中client 的时间最长.或者其他的,这些就要根据你自己的测试结果来分析了。下面我们来看一下CPU,内存.硬盘的瓶颈分析方法:
首先我们要监视CPU,内存.硬盘的资源情况.得到以下的参数提供分析的依据.
%processor time(processor_total):器消耗的处理器时间数量.如果服务器专用于sql server 可接受的最大上限是80% -85 %.也就是常见的CPU 使用率.
%Usertime(processor_total)::表示耗费CPU的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。
%DPC time(processor_total)::越低越好。在多处理器系统中，如果这个值大于50%并且Processor:%Processor Time非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。
%Disktime(physicaldisk_total):指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器（%Diskreads/sec(physicaldisk_total)、%Diskwrite/sec(physicaldisk_total)）都比较大，那么硬盘不是瓶颈。如果只有%Disk Time比较大，另外两个都比较适中，硬盘可能会是瓶颈。在记录该计数器之前，请在Windows 2000 的命令行窗口中运行diskperf -yD。若数值持续超过80%，则可能是内存泄漏。
Availiablebytes(memory):用物理内存数. 如果Available Mbytes的值很小(4 MB 或更小)，则说明计算机上总的内存可能不足，或某程序没有释放内存。
Contextswitch/sec(system): (实例化inetinfo 和dllhost 进程) 如果你决定要增加线程字节池的大小，你应该监视这三个计数器(包括上面的一个)。增加线程数可能会增加上下文切换次数，这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高，就应该减小线程字节池的大小。
%Diskreads/sec(physicaldisk_total):每秒读硬盘字节数.
%Diskwrite/sec(physicaldisk_total):每秒写硬盘字节数.
Page faults/sec:进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。
Pages per second:每秒钟检索的页数。该数字应少于每秒一页Working set:理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。
Avg.disk queuelength:读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。该值应不超过磁盘数的1.5~2 倍。要提高性能，可增加磁盘。注意：一个Raid Disk实际有多个磁盘。
Average disk read/writequeue length: 指读取(写入)请求(列队)的平均数Diskreads/(writes)/s:理磁盘上每秒钟磁盘读、写的次数。两者相加，应小于磁盘设备最大容量。
Average disksec/read:以秒计算的在此盘上读取数据的所需平均时间。Average disksec/transfer:指以秒计算的在此盘上写入数据的所需平均时间。
Bytes total/sec:为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较Page read/sec:每秒发出的物理数据库页读取数。这一统计信息显示的是在所有数据库间的物理页读取总数。由于物理 I/O 的开销大，可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法，使开销减到最小。
Page write/sec:(写的页/秒)每秒执行的物理数据库写的页数。
内容导航
1. 判断应用程序的问题
如果系统由于应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换(context switches/sec显示的上下文切换次数太高)那么就会占用大量的系统资源,如果系统的吞吐量降低并且CPU的使用率很高,并且此现象发生时切换水平在15000以上,那么意味着上下文切换次数过高.
从图的整体看.contextswitches/sec变化不大,throughout曲线的斜率较高,并且此时的contextswitches/sec已经超过了15000.程序还是需要进一步优化.
2. 判断CPU瓶颈
如果processor queuelength显示的队列长度保持不变(>=2)个并且处理器的利用率%Processortime超过90%,那么很可能存在处理器瓶颈.如果发现processor queuelength显示的队列长度超过2,而处理器的利用率却一直很低,或许更应该去解决处理器阻塞问题,这里处理器一般不是瓶颈.
%processor time平均值大于95,processor queue length大于2.可以确定CPU瓶颈.此时的CPU已经不能满足程序需要.急需扩展.
3. 判断内存泄露问题
内存问题主要检查应用程序是否存在内存泄漏,如果发生了内存泄漏,process\privatebytes计数器和process\working set 计数器的值往往会升高,同时avaiable bytes的值会降低.内存泄漏应该通过一个长时间的,用来研究分析所有内存都耗尽时,应用程序反应情况的测试来检验.
图中可以看到该程序并不存在内存泄露的问题.内存泄露问题经常出现在服务长时间运转的时候,由于部分程序对内存没有释放,而将内存慢慢耗尽.也是提醒大家对系统稳定性测试的关注.
附件:
1、CPU信息：
Processor\ %Processor Time 获得处理器使用情况。
也可以选择监视 Processor\ %User Time 和 % Privileged Time 以获得详细信息。
Server Work Queues\Queue Length 计数器会显示出处理器瓶颈。队列长度持续大于 4 则表示可能出现处理器拥塞。
System\ ProcessorQueue Length 用于瓶颈检测通过使用 Process\ %Processor Time 和 Process\ WorkingSet
Process\ % ProcessorTime过程的所有线程在每个处理器上的处理器时间总和。
硬盘信息：
Physical Disk\ %Disk Time
Physical Disk\Avg.Disk Queue Length
例如，包括 PageReads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果页面读取操作速率很低，同时 % Disk Time 和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。
Physical Disk\ %Disk Time
Physical Disk\Avg.Disk Queue Length
例如，包括 PageReads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果页面读取操作速率很低，同时 % Disk Time 和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。
请观察 Processor\Interrupts/sec 计数器的值，该计数器测量来自输入/输出 (I/O) 设备的服务请求的速度。如果此计数器的值明显增加，而系统活动没有相应增加，则表明存在硬件问题。
Physical Disk\ DiskReads/sec and Disk Writes/sec
Physical Disk\Current Disk Queue Length
Physical Disk\ %Disk Time
LogicalDisk\ % FreeSpace
测试磁盘性能时，将性能数据记录到另一个磁盘或计算机，以便这些数据不会干扰您正在测试的磁盘。
可能需要观察的附加计数器包括 PhysicalDisk\ Avg.Disk sec/Transfer 、Avg.DiskBytes/Transfer，和Disk Bytes/sec。
Avg.Disksec/Transfer 计数器反映磁盘完成请求所用的时间。较高的值表明磁盘控制器由于失败而不断重试该磁盘。这些故障会增加平均磁盘传送时间。对于大多数磁盘，较高的磁盘平均传送时间是大于 0.3 秒。
也可以查看 Avg.DiskBytes/Transfer 的值。值大于 20 KB 表示该磁盘驱动器通常运行良好;如果应用程序正在访问磁盘，则会产生较低的值。例如，随机访问磁盘的应用程序会增加平均 Disk sec/Transfer 时间，因为随机传送需要增加搜索时间。
Disk Bytes/sec 提供磁盘系统的吞吐率。
决定工作负载的平衡要平衡网络服务器上的负载，需要了解服务器磁盘驱动器的繁忙程度。使用 Physical Disk\ %Disk Time 计数器，该计数器显示驱动器活动时间的百分比。如果 % Disk Time 较高(超过90%)，请检查 Physical Disk\Current Disk Queue Length 计数器以查看正在等待磁盘访问的系统请求数量。等待 I/O 请求的数量应当保持在不大于组成物理磁盘的主轴数的 1.5 到2倍。
尽管廉价磁盘冗余阵列 (RAID) 设备通常有多个主轴，大多数磁盘有一个主轴。硬件 RAID设备在“系统监视器”中显示为一个物理磁盘;通过软件创建的 RAID 设备显示为多个驱动器(实例)。可以监视每个物理驱动器(而不是 RAID)的 Physical Disk 计数器，也可以使用 _Total 实例来监视所有计算机驱动器的数据。
使用 Current Disk QueueLength 和 % Disk Time 计数器来检测磁盘子系统的瓶颈。如果Current Disk Queue Length 和 % Disk Time 的值始终较高，可以考虑升级磁盘驱动器或将某些文件移动到其他磁盘或服务器。
2、软件测试中性能调优的过程解析 性能调优无疑是个庞大的话题，也是很多项目中非常重要的一环，性能调优的难做是众所周知的，毕竟性能调优涵盖的面实在是太多了，在这篇文章中我们蜻蜓点水般的来看看性能调优这项庞大的工程都有些什么过程，同时也看看这些过程中常见的一些做法。 确定性能调优的目标 性能调优，首先是要确定性能调优的目标是什么，如果现在应用已经满足了需求，就没必要去做性能调优了，毕竟不经过一个系统的过程，其实是无法确定你所做的性能调整是否真的调优了性能，是否没有造成应用中其他的问题，所以确定性能目标是非常重要的，在定义性能目标的时候通常这么定义的呢： 1、最大并发数 2、Qualityof Service 服务的质量，在软件系统方面我们认为主要表现在请求的出错率，系统的load等。
3、最长响应时间 对于任何请求所能承受的最大响应时间。 4、TPS 每秒需要支持的最大事务数，最典型的指标是：“某页面最高需要支撑每秒7000次的访问次数”。 例如一个web系统，需要定义出来的目标是： 并发目标：最高支撑200并发; QoS：出错率须控制在万分之一，系统的load最高只能到达10; TPS：每秒完成7000次请求的处理; 最大响应时间：最长允许的响应时间为5秒。 至于请求的平均响应时间这些就不在性能调优目标中定义，因为要达到TPS的要求，响应时间是必须要达到一个级别的，而且响应时间随着高并发是会出现劣化的。 当然，还可以把性能指标定到更为细节，例如某个方法的TPS在100并发时需要达到多少。 在确定好了性能目标后，重要的就是如何来测量系统的性能了。 测量系统性能 对于新系统而言，需要评估出其正式运行时的数据量的增长情况;而对于已运行的系统，则需要根据监控获取到系统的运行数据(例如高峰并发数、系统的响应速度情况、系统的load、网络流量、每类请求在总的请求中所占的百分比等)。 对于新系统而言，要评估出具体的性能相对来说稍微好做一点，因为此时系统通常较为单纯，数据量的增长也不可能是一夜之间增长的，因此基本可以按照一种正常的方法在测试环境评估出其正式运行的性能。 而对于已运行的系统而言，则较为麻烦，因为通常来讲要在测试环境中模拟正式运行环境基本是不太可能的，因此这个时候通常要采取一些模拟的方法或更高压力的方法来尽量更为准确的评估出系统的性能。 在测试系统性能时，通常可采用的方法有： 1、单元测试; 可借助单元测试来测试某个请求的性能; 2、压力测试; 压力测试无疑是测量系统性能中最常采用的方式，根据定义的性能目标对系统进行压力测试，以确定系统是否满足性能要求，同时也可以根据压力测试的结果来分析系统的瓶颈，进而进行对应的调优，可用于做压力测试的工具还是不少的，像loadrunner、jmeter等等，不过压力测试这个话题实在太大了，不在这里展开去讲了，不过我也不怎么懂就是，呵呵。 分析系统性能瓶颈 根据测量系统性能的结果，多数是可以分析出系统性能的瓶颈，同时还可以结合像jvm堆栈、jprofiler、系统日志等来进行进一步的确定，另外也可以根据性能调优人员的经验，例如可以去了解开发人员是否采用了不适合的数据结构等。 简单说一个线程分析的例子： 借助kill-3 pid来获取到目前jvm的线程堆栈信息，特别需要关注的是里面waitfor monitor这样的线程，这种线程是指在等待锁的线程，等待一两分钟后再。
注：以下指标取自Oracle的性能分析工具Statspack所提供的性能分析指标。
| 指标名称 | 指标描述 | 指标范围 | 指标单位 |
| 1．关于实例效率（Instance Efficiency Percentages）的性能指标 | |||
| 缓冲区未等待率 (Buffer Nowait %) | 指在缓冲区中获取Buffer的未等待比率。 | 该指标的值应接近100%，如果该值较低，则可能要增大buffer cache。 | % |
| Redo缓冲区未等待率 (Redo NoWait %) | 指在Redo缓冲区获取Buffer的未等待比率。 | 该指标的值应接近100%，如果该值较低，则有2种可能的情况： 1） online redo log没有足够的空间； 2）log切换速度较慢。 | % |
| 缓冲区命中率 (Buffer Hit %) | 指数据块在数据缓冲区中的命中率。 | 该指标的值通常应在90%以上，否则，需要调整。如果持续小于90%，可能要加大db_cache_size。但有时，缓存命中率低并不意味着cache设置小了，可能是潜在的全表扫描降低了缓存命中率。 | % |
| 内存排序率 | 指排序操作在内存中进行的比率。当查询需要排序的时候，数据库会话首先选择在内存中进行排序，当内存大小不足的时候，将使用临时表空间进行磁盘排序，但磁盘排序效率和内存排序效率相差好几个数量级。 | 该指标的值应接近100%，如果指标的值较低，则表示出现了大量排序时的磁盘I/O操作，可考虑加大sort_area_size参数的值。 | % |
| 共享区命中率 (Library Hit %) | 该指标主要代表sql在共享区的命中率。 | 该指标的值通常应在95%以上，否则需要考虑加大共享池（修改shared_pool_size参数值），绑定变量，修改cursor_sharing等参数。 | % |
| 软解析的百分比 (Soft Parse %) | 该指标是指Oracle对sql的解析过程中，软解析所占的百分比。软解析（soft parse）是指当Oracle接到Client提交的Sql后会首先在共享池（Shared Pool）里面去查找是否有之前已经解析好的与刚接到的这一个Sql完全相同的Sql。当发现有相同的Sql就直接用之前解析好的结果，这就节约了解析时 间以及解析时候消耗的CPU资源。 | 该指标的值通常应在95%以上，如果低于80%，那么就可能sql基本没被重用，sql没有绑定变量，需要考虑绑定变量。 | % |
| 闩命中率 (Latch Hit %) | 指获得Latch的次数与请求Latch的次数的比率。
| 该指标的值应接近100%，如果低于99%，可以考虑采取一定的方法来降低对Latch的争用。 | % |
| SQL语句执行与 解析的比率 (Execute to Parse %) | 指SQL语句执行与解析的比率。SQL语句一次解析后执行的次数越多，该比率越高，说明SQL语句的重用性很好。
| 该指标的值应尽可能到高，如果过低，可以考虑设置 | % |
| 共享池内存使用率 (Memory Usage %) | 该指标是指在采集点时刻，共享池（share pool）内存被使用的比例。 | 这指标的值应保持在75%~90%,如果这个值太低，就浪费内存，如果太高，会使共享池外部的组件老化，如果SQL语句被再次执行，则就会发生硬分析。 | % |
| 2．关于等待事件（Wait events）的性能指标 | |||
| 文件分散读取 (db file scattered read (cs)) | 该等待事件通常与全表扫描有关。因为全表扫描是被放入内存中进行的进行的，通常情况下它不可能被放入连续的缓冲区中，所以就散布在缓冲区的缓存中。 | 如果这个等待事件比较显著，可能说明对于某些全表扫描的表，没有创建索引或没有创建合适的索引。尽管在特定条件下执行全表扫描可能比索引扫描更有效，但如果出现这种等待时，最好检查一下这些全表扫描是否必要。 | 厘秒 |
| 文件顺序读取 (db file sequential read (cs)) | 该等待事件通常与单个数据块相关的读取操作有关。 | 如果这个等待事件比较显著，可能表示在多表连接中，表的连接顺序存在问题，或者可能不合适地使用了索引。对于大量事务处理、调整良好的系统，这一数 值大多是很正常的，但在某些情况下，它可能暗示着系统中存在问题。应检查索引扫描，以保证每个扫描都是必要的，并检查多表连接的连接顺序。另外 DB_CACHE_SIZE 也是这些等待出现频率的决定因素。 | 厘秒 |
| 缓冲区忙 (buffer busy (cs)) | 当一个会话想要访问缓存中的某个块，而这个块正在被其它会话使用时，将会产生该等待事件。这时候，其它会话可能正在从数据文件向缓存中的这个块写入信息，或正在对这个块进行修改。 | 出现这个等待事件的频度不应大于1%。如果这个等待事件比较显著，则需要根据等待事件发生在缓存中的哪一块（如字段头部、回退段头部块、回退段非头部块、数据块、索引块等），采取相应的优化方法。
| 厘秒 |
|
(enqueue (cs)) | enqueue 是一种保护共享资源的锁定机制。该锁定机制保护共享资源，如记录中的数据，以避免两个人在同一时间更新同一数据。enqueue 包括一个排队机制，即FIFO(先进先出)排队机制。注意：Oracle 的latch 机制不是FIFO。Enqueue 等待通常指的是ST enqueue、HW enqueue、TX4 enqueue 和TM enqueue。 | 如果enqueue等待事件比较显著，则需要根据enqueue等待类型，采取相应的优化方法。 | 厘秒 |
| 闩释放 (latch free (cs)) | 该等待事件意味着进程正在等待其他进程已持有的latch。 latch是一种低级排队机制(它们被准确地称为相互排斥机制),用于保护系统全局区域(SGA)中共享内存结构。latch 就像是一种快速地被获取和释放的内存锁。latch 用于防止共享内存结构被多个用户同时访问。 | 对于常见的Latch等待通常的解决方法： 1）Share pool latch：在OLTP应用中应该更多的使用绑定变量以减少该latch的等待。 2）Library cache latch：同样的需要通过优化sql语句使用绑定变量减少该latch的等待。 | 厘秒 |
| 日志文件同步 (log file sync (cs)) | 这个等待事件是指当一个会话完成一个事务（提交或者回滚数据）时，必须等待LGWR进程将会话的redo信息从日志缓冲区写到日志文件后，才能继续执行下去。 | 这个等待事件的时间过长，可能是因为commit太频繁或者lgwr进程一次写日志的时间太长（可能是因为一次log io size太大），可调整 _log_io_size，结合log_buffer,使得 (_log_io_size*db_block_size)*n = log_buffer，这样可避免和增大log_buffer引起冲突，或者可以将日志文件存放在高速磁盘上 | 厘秒 |
解决方案：1.确保防火墙安全软件关闭；
2.确保负载机上的agent启动，并且查看日志没有报错，如果有报错，使用该命令netstat -nab查看80端口是否被占用，因为
agent服务使用80端口(要是被占用多半是inetinfo.exe,IIS服务器的服务，不用多说了，关掉该服务)；
3.network dde 和network ddedsdm服务开启；
扫一扫
81
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
