性能测试-各环节监控

oracle的一个实例的链接不能超过2万

nginx在7层、F5在4层，Nginx可以根据内容分发，F5只能识别IP和端口

mongdb用在最常用的查询场景

redias是key-value类型的数据库，最大的优势是内存上跑

页面基础原则：单页面不超过1s

weblogic

1、xms（JVM初始分配的堆内存）内存最大，xmx（JVM最大允许分配的堆内存）内存最小值、xmn是xms和xmx的新生代，是xms的0.25。xmx要大于xms

a.内存大小一致最好

b.分配1.5~4G合适，因为这个和GC成反比，内存越大。GC回收的频率越低，GC会抢占CPU，会造成系统卡顿。

c.新生代（xmn）对weblogic宕机起着很好的延缓作用。为新的请求总是会预留一定的空间；

d.统计full GC的次数（老年代满了 or 新生代里判断为老年代的内容大于老年代理可以存储的大小时）如果次数在增长，就一定说明内存出问题了。

2、PermSize和MaxPermSize

a.PermSize=64m JVM初始分配的非堆内存

b.MaxPermSize=256m JVM最大允许分配的非堆内存

c.permSize存放java编译以后的class

d.满了weblogic就会崩，并且不会自动增大。

e.PermSize建议设置为384M，默认128M

e.PermSize和MaxPermSize指明虚拟机为java永久生成对象（Permanate generation）如，class对象、方法对象这些可反射（reflective）对象分配内存限制，这些内存不包括

在Heap（堆内存）区之中，MaxPermSize过小会导致：java.lang.OutOfMemoryError: PermGen space

3、wls（组件漏洞）启动最小线程数400，不能超过1000，否则wls会崩

4、套接字复用器，请求进来的时候会在套接字复用器里面建立和分配soket，如果启用本地io，就可以省去建立的时间。

5、接受积压（排队长度）：每次扩大长度时，以原来的0.25倍增长；

6、登录超时：与服务器最后一次交互到自动断开的持续时间，0.5到2小时合适

7、反向DNS查找

a.千万不能点，会下降性能

b.通过应用反查ip

8、日志

a.对性能影响很大，因为涉及io

b.如果一定要打日志，那么可以采取异步打印，设置缓冲区，将缓存区占满后，一起打印。对性能提升很大；

9、keep-alive（weblogic的一个设置项）保持长链接，长连接比短连接提升30%的tps

Tomcat

1、共享线程池

2、同步阻塞型连接

3、异步非阻塞连接

三层缓存

应用缓存  Nginx

物理缓存  cdn

关系型数据库：acid保持数据一致，有关联查询

非关系型数据库：key和value可以不限结构的存储。redias（缓存）、mongdb（查询量比较大，比较固定，比较频繁使用）

redis

主要使用内存的技术

1、sava  对性能影响不大

2、get的命中率（大于99%），如果有很多找不着的连接，就会占用很多内存；

redis提供了INFO这个命令，能够随时监控服务器的状态，只用telnet到对应服务器的端口，执行命令即可：

[html] view plain copy

  1. telnet localhost 6379
  2. info

在输出的信息里面有这几项和缓存的状态比较有关系：

[html] view plain copy

  1. keyspace_hits:14414110
  2. keyspace_misses:3228654
  3. used_memory:433264648
  4. expired_keys:1333536
  5. evicted_keys:1547380

通过计算hits和miss，我们可以得到缓存的命中率：14414110 / (14414110 + 3228654) = 81% ，一个缓存失效机制，和过期时间设计良好的系统，命中率可以做到95%以上

3、连接的使用，看是否接近maxclients

使用命令info查看连接数connected_clients：357

4、vm-enabled no 虚拟内存一般不启用

指定是否启用虚拟内存机制，默认值为no，简单的介绍一下，VM机制将数据分页存放，由Redis将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘自动换出到内存中

5、请求100ms以内比较好

6、Redis是单线程模式，所有命令都是按照顺序执行的；

Nginx

1、解决安全问题

a、请求数足够大，5万以上没有问题

b、反向代理，不暴露应用的IP地址

2、多路复用机制，epool

3、Nginx组件配置

a、worker_processes 等于CPU的数量

b、Worker_connections大一些都无所谓，65535都没有问题，实际上10000左右会被用作管理

c、Server_name主机名

d、Sendfile  on 内存复制模式，来判断是否要压缩。

e、请求缓存（二级），一级：client_header_bufer_size可以设大一点，减少二级的分配过程。二级：large_client_header_buffes。如果报文比二级还大，就会返回400错误

代码

表现层：

a、用户客户端：加载权限数，目录树需要较大内存，java里会使用懒加载

工具

1、问题分析：httpwatch

2、出报告：yslow（评分C一下的要修改）

3、Dynatrace（分析js，正常加载页面是并行的，边接受边解析边渲染。但是遇到 js就要停止以上动作，因为js可能会改写解析出来的树，所以要尽量少用js，尽量在最后加载js）

4、降低像素，处理资源：pagetest（主要检测要处理的图片等资源）

5、优化点：a.代码里一定要设置cache；b.一个页面的请求控制在60-70以下；c.响应时间排序，看看慢的是不是报文大。看accept-encoding是否用了gzip，如果图片多，需要压缩。看time chart，具体哪个阶段慢？看connection是否keep-alive

b、前台代码

逻辑层

a、工具

1、Jvsualvm

以jdk1.6update45(jdk1.6update45自带的jvisualvm)来做说明，当然也可单独下载独立的jvisualvm，正常安装完jdk后，至jdk的bin目录下，运行jvisualvm.exe即可，程序运行后会自动监控本机运行的java程序（Local标签下，远程服务器上的java程序需要另行配置）

监控项总共分为Overview，Monitor，Threads和一个Sampler。

1.Overview（jvm启动参数，系统参数）

可以看到eclipse的启动参数

(通过这些启动参数，可以判断程序是否有内存溢出)

2.Monitor

左上：cpu利用率，gc状态的监控

右上：堆利用率，永久内存区的利用率

左下：类的监控

右下：线程的监控

performGC：gc的详细运行状态

HeapDump：堆的详细状态（可以看到堆的概况，里面所有的类，还能点进具体的一个类查看这个类的状态）

3.Threads

能够显示线程的名称和运行的状态，在调试多线程时必不可少，而且可以点进一个线程查看这个线程的详细运行情况

监控服务器上的tomcat

tomcat的配置文件catalina.sh中增加:

[plain] view plain copy

  1. JAVA_OPTS="-Dcom.sun.management.jmxremote.port=9998
  2. -Dcom.sun.management.jmxremote.ssl=false
  3. -Dcom.sun.management.jmxremote.authenticate=false
  4. -Djava.rmi.server.hostname=192.168.58.164"

参数说明:

[plain] view plain copy

  1. 指定了JMX启动的代理端口，这个端口就是visualvm要连接的端口（9998端口不能被别的程序使用netstat -an|gerp 9998）
  2. Dcom.sun.management.jmxremote.port=9998
  3. 指定了JMX是否启用ssl
  4. Dcom.sun.management.jmxremote.authenticate=false
  5. 指定了JMX是否启用鉴权（需要用户名，密码鉴权）
  6. Dcom.sun.management.jmxremote.authenticate=false
  7. 指定了服务器主机名
  8. Djava.rmi.server.hostname=192.168.58.164

填写主机名：

右键创建一个jmx连接：

填写上端口号即可：

配置完成：

2、Jprofiler

JProfiler是由ej-technologies GmbH公司开发的一款性能瓶颈分析工具(该公司还开发部署工具)。

其特点:

  • 使用方便
  • 界面操作友好
  • 对被分析的应用影响小
  • CPU,Thread,Memory分析功能尤其强大
  • 支持对jdbc,noSql, jsp, servlet, socket等进行分析
  • 支持多种模式(离线，在线)的分析
  • 跨平台  (图1)

二.数据采集

Q1. JProfiler既然是一款性能瓶颈分析工具，这些分析的相关数据来自于哪里？

Q2. JProfiler是怎么将这些数据收集并展现的?

(图2)

A1. 分析的数据主要来自于下面俩部分

1. 一部分来自于jvm的分析接口**JVMTI**(JVM Tool Interface) , JDK必须>=1.6

JVMTI is an
event-based system. The profiling agent library can register handler functions
for different events. It can then enable or disable selected events

例如: 对象的生命周期，thread的生命周期等信息

2. 一部分来自于instruments classes(可理解为class的重写,增加JProfiler相关统计功能)

例如：方法执行时间，次数，方法栈等信息

A2. 数据收集的原理如图2

1. 用户在JProfiler GUI中下达监控的指令(一般就是点击某个按钮)

2. JProfiler GUI JVM 通过socket(默认端口8849)，发送指令给被分析的jvm中的JProfile Agent。

3. JProfiler Agent(如果不清楚Agent请看文章第三部分"启动模式") 收到指令后，将该指令转换成相关需要监听的事件或者指令,来注册到JVMTI上或者直接让JVMTI去执行某功能(例如dump jvm内存)

4. JVMTI 根据注册的事件，来收集当前jvm的相关信息。 例如: 线程的生命周期; jvm的生命周期;classes的生命周期;对象实例的生命周期;堆内存的实时信息等等

5. JProfiler Agent将采集好的信息保存到**内存**中，按照一定规则统计好(如果发送所有数据JProfiler GUI，会对被分析的应用网络产生比较大的影响)

6. 返回给JProfiler GUI Socket.

7. JProfiler GUI Socket 将收到的信息返回 JProfiler GUI Render

8. JProfiler GUI Render 渲染成最终的展示效果

三. 数据采集方式和启动模式

A1. JProfier采集方式分为两种：Sampling(样本采集)和Instrumentation

Sampling: 类似于样本统计, 每隔一定时间(5ms)将每个线程栈中方法栈中的信息统计出来。优点是对应用影响小(即使你不配置任何Filter, Filter可参考文章第四部分)，缺点是一些数据/特性不能提供(例如:方法的调用次数)

Instrumentation: 在class加载之前，JProfier把相关功能代码写入到需要分析的class中，对正在运行的jvm有一定影响。优点: 功能强大，但如果需要分析的class多，那么对应用影响较大，一般配合Filter一起使用。所以一般JRE class和framework的class是在Filter中通常会过滤掉。

注: JProfiler本身没有指出数据的采集类型，这里的采集类型是针对方法调用的采集类型 。因为JProfiler的绝大多数核心功能都依赖方法调用采集的数据, 所以可以直接认为是JProfiler的数据采集类型。

A2: 启动模式:

Attach mode

可直接将本机正在运行的jvm加载JProfiler Agent. 优点是很方便，缺点是一些特性不能支持。如果选择Instrumentation数据采集方式，那么需要花一些额外时间来重写需要分析的class。

Profile at startup

在被分析的jvm启动时，将指定的JProfiler Agent手动加载到该jvm。JProfiler GUI 将收集信息类型和策略等配置信息通过socket发送给JProfiler Agent，收到这些信息后该jvm才会启动。

在被分析的jvm 的启动参数增加下面内容：

语法: -agentpath:[path
to jprofilerti library]

【注】: 语法不清楚没关系，JProfiler提供了帮助向导.

(图3)

Prepare for profiling:

和Profile at startup的主要区别：被分析的jvm不需要收到JProfiler GUI 的相关配置信息就可以启动。

Offline profiling

一般用于适用于不能直接调试线上的场景。Offline profiling需要将信息采集内容和策略(一些Trigger, Trigger请参考文章第五部分)打包成一个配置文件(config.xml)，在线上启动该jvm 加载 JProfiler Agent时，加载该xml。那么JProfiler Agent会根据Trigger的类型会生成不同的信息。例如: heap dump; thread
dump; method call record等

语法:

-agentpath:/home/2080/jprofiler8/bin/Linux-x64/libjprofilerti.so=offline,id=151,config=/home/2080/config.xml

【注】: config.xml中的每一个被分析的jvm的采集信息都有一个id来标识。

下面是使用了离线模式，并使用了每隔一秒dump heap 的Trigger：

四. JProfiler核心概念

Filter: 什么class需要被分析。分为包含和不包含两种类型的Filter。

(图4)

Profiling Settings: 收据收集的策略:Sampling和 Instrumentation，一些数据采集细节可以自定义.

(图5)

Triggers: 一般用于**offline**模式，告知JProfiler Agent 什么时候触发什么行为来收集指定信息.

(图6)

Live memory: class/class instance的相关信息。 例如对象的个数，大小，对象创建的方法执行栈，对象创建的热点。

(图7)

Heap walker: 对一定时间内收集的内存对像信息进行静态分析，功能强大且使用。包含对象的outgoing reference,
incoming reference, biggest object等

(图8)

CPU views: CPU消耗的分布及时间(cpu时间或者运行时间); 方法的执行图; 方法的执行统计(最大，最小，平均运行时间等)

(图9)

Thread: 当前jvm所有线程的运行状态，线程持有锁的状态，可dump线程。

(图10)

Monitors & locks: 所有线程持有锁的情况以及锁的信息

(图11)

Telemetries: 包含heap, thread, gc, class等的趋势图(遥测视图)

五. 实践

为了方便实践，直接以JProfiler8自带的一个例子来帮助理解上面的相关概念。

JProfiler 自带的例子如下：模拟了内存泄露和线程阻塞的场景：

具体源码参考: /jprofiler install
path/demo/bezier

(图12 )

(图13 Leak Memory 模拟内存泄露, Simulate blocking 模拟线程间锁的阻塞)

A1. 首先来分析下内存泄露的场景:(勾选图13中 Leak Memory 模拟内存泄露)

1. 在**Telemetries-> Memory**视图中你会看到大致如下图的场景(在看的过程中可以间隔一段时间去执行Run GC这个功能)：看到下图蓝色区域,老生代在gc后(**波谷**)内存的大小在慢慢的增加(理想情况下，这个值应该是稳定的)

(图14)

在 Live memory->Recorded Objects 中点击**record allocation
data**按钮，开始统计一段时间内创建的对象信息。执行一次**Run GC**后看看当前对象信息的大小，并点击工具栏中**Mark Current**按钮(其实就是给当前对象数量打个标记。执行一次Run GC，然后再继续观察;执行一次Run GC，然后再继续观察...。最后看看哪些对象在不断GC后，数量还一直上涨的。最后你看到的信息可能和下图类似

(图15 绿色是标记前的数量，红色是标记后的增量)

在Heap walker中分析刚才记录的对象信息

(图16)

(图17)

点击上图中实例最多的class，右键**Use Selected
Instances->Reference->Incoming Reference**.

发现该Long数据最终是存放在**bezier.BeaierAnim.leakMap**中。

(图18)

在Allocations tab项中，右键点击其中的某个方法，可查看到具体的源码信息.

(图19)

【注】:到这里问题已经非常清楚了，明白了在图17中为什么哪些实例的数量是一样多，并且为什么内存在fullgc后还是回收不了(一个old 区的对象leakMap，put的信息也会进入old区, leakMap如回收不掉，那么该map中包含的对象也回收不掉)。

A2. 模拟线程阻塞的场景(勾选图13中Simulate blocking 模拟线程间锁的阻塞)

为了方便区分线程，我将Demo中的BezierAnim.java的L236的线程命名为test

public void start() {
            thread = new Thread(this, "test");
            thread.setPriority(Thread.MIN_PRIORITY);
            thread.start();
        }

正常情况下，如下图

(图20)

勾选了Demo中"Simulate blocking"选项后，如下图(注意看下下图中的状态图标), test线程block状态明显增加了。

(图21)

在**Monitors & locks->Monitor
History**观察了一段时间后，会发现有4种发生锁的情况。

第一种:

AWT-EventQueue-0 线程持有一个Object的锁，并且处于Waiting状态。

图下方的代码提示出Demo.block方法调用了object.wait方法。这个还是比较容易理解的。

(图22)

第二种:

AWT-EventQueue-0占有了bezier.BezierAnim$Demo实例上的锁，而test线程等待该线程释放。

注意下图中下方的源代码, 这种锁的出现原因是Demo的blcok方法在AWT和test线程

都会被执行，并且该方法是synchronized.

(图23)

第三种和第四种:

test线程中会不断向事件Event Dispatching Thread提交任务，导致竞争java.awt.EventQueue对象锁。

提交任务的方式是下面的代码:repaint()和EventQueue.invokeLater

        public void run() {
            Thread me = Thread.currentThread();
            while (thread == me) {
                repaint();
                if (block) {
                    block(false);
                }
                try {
                    Thread.sleep(10);
                } catch (Exception e) {
                    break;
                }
                EventQueue.invokeLater(new Runnable() {
                    @Override
                    public void run() {
                        onEDTMethod();
                    }
                });
            }
            thread = null;
        }

(图24)

六. 最佳实践

  1. JProfiler都会对一些特殊操作给予提示，这时候最好仔细阅读下说明.
  2. "Mark Current"功能在某些场景很有效
  3. Heap walker一般是静态分析在Live memory->Recorder objects的对象信息，这些信息可能会被GC回收掉，导致Heap walker中什么也没有显示出来。这种现象是正常的。
  4. 可以才工具栏中Start Recordings配置一次性收集的信息
  5. Filter中include和exclude是有顺序的，注意使用下图**左下方**的**“Show Filter Tree”**来验证一下顺序  (图25)
  6. JProfiler helper: http://resources.ej-technologies.com/jprofiler/help/doc/index.html

七. 参考文献

JVMTI: http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html

b、优化点

1、不要在嵌套中抛出异常

2、不要在异常中处理业务逻辑

3、尽量使用局部变量，局部变量比全局变量块2到3倍

数据层

工具

spotlight

原文地址：https://www.cnblogs.com/shuyichao/p/10384777.html

时间： 2024-08-30 00:37:33

性能测试-各环节监控的相关文章

性能测试-Hbase Hadoop监控

以前做过一个性能测试项目,基于nginx+Hbase+Hadoop,第一次接触开源的东西,遇到各种问题,印象深的是Hbase和Hadoop的监控,当时也搜索到可以用开源的监控工具或写代码通过JMX取JVM的信息.在摸索的过程中发现一种更简单方便的办法,不用监控工具和写大量代码,直接用loadrunner脚本(该办法可能不专业,但是能用,可以让项目尽快进行,仅供参考). 我们知道Hbase开放了60010和60030端口,Hadoop开放的50070端口,以web的方式查看master.regio

性能测试(测试指标监控策略汇总)

监控类别 监控指标 监控工具或命令 APP前端 响应时间.吞吐量.TPS.点击率.超时概率.错误概率.页面性能 工具:ddms25.页面工具:YSlow3.1.ChromDevTools(基于Chrome57)综合工具:GT.Emmagee 应用服务器(jvm和配置) JVM.最大线程数.DB连接数.full gc频率.是否有异常日志.是否有OOM.内存泄露.代码异常.线程死锁 工具:jvisualvm(基于jdk1.7)工具:MemoryAnalyzer1.6命令:jps jinfo jsta

性能测试-Linux资源监控?式

Linux资源监控?式 1. 命令 2. 第三??具(nmon) 3. LR(需要安装RPC相应服务包和开启服务)(略) ?.命令 ?式 1. top (系统资源管理器) 2. vmstat (查看虚拟内存状态) 3. free(查看未使?的和已使?的内存数?) 4. iostat (查看io磁盘信息) 5. sar ?络 1.1 命令 top(系统资源管理器) 说明: 1). top命令类似与windows的任务管理器,查看内存.CPU.进程等操作信息 2). 在Linux系统中常?top命令

性能测试监控策略汇总

性能测试(测试指标监控策略汇总) 监控类别 监控指标 监控工具或命令 APP前端 响应时间.吞吐量.TPS.点击率.超时概率.错误概率.页面性能 工具:ddms25.页面工具:YSlow3.1.ChromDevTools(基于Chrome57)综合工具:GT.Emmagee 应用服务器(jvm和配置) JVM.最大线程数.DB连接数.full gc频率.是否有异常日志.是否有OOM.内存泄露.代码异常.线程死锁 工具:jvisualvm(基于jdk1.7)工具:MemoryAnalyzer1.6

最简单也最难：运维监控的最后1公里

谈运维我们不得不提监控,监控是运维的起点,也是难点.随着IT架构逐渐复杂化,从前端到IT底层,中间涉及浏览器.网络.服务器.操作系统.中间件.应用.数据库等,每个环节厂商不尽相同.当出现异常需要定位哪个环节出了问题的时候,排查就耗时耗力,若使用优云监控产品,以上难题不再是问题.优云全栈运维监控覆盖了所有环节的监控,真正做到监控无盲区,运维无隐患. 运维最后一公里是指高度可视化.优云除了提升监控能力还注重可视化,深知可视化是运维的亮点更是本质,为了让每个环节监控的数据更好的展现出来,优云拥有一批在

转载：JProfiler远程监控LINUX上的Tomcat过程细讲

来源于xuwanbest的博客 所谓"工欲善其事,必先利其器",好的工具确能起到事半工倍的作用.我用到的最多的就两个JConsole 和JProfiler .JConsole监控系统内存变化情况,如果有内存溢出的话,垃圾回收将会呈现锯齿状.发现问题以后,使用JProfiler,在小压力(或无压力)的情况下监控对象变化,定位内存溢出原因. JProfiler是一款Java的性能监控工具.可以查看当前应用的对象.对象引用.内存.CPU使用情况.线程.线程运行情况(阻塞.等待等),同时可以查

性能测试步骤

系统性能测试中的几大步骤 1.明确测试目标:了解性能测试需求: 2.编写性能测试计划: 3.分析性能测试需求: 4.编写性能测试方案,设计测试场景: 5.相关资源准备(人力资源,硬件资源,软件资源): 6.测试程序开发:脚本维护,测试数据准备,测试监控准备: 7.执行性能测试并收集测试结果: 8.分析结果: 9.系统调优及再测试: 1.明确测试目标:了解性能测试需求:     性能测试启动阶段要确定测试的负责人和组织结构.明确测试的总体目标和范围,确认资源情况.获取 性能测试需求:业务列表,性能

LR杂记 - 性能测试指标及常用的监控工具

监控指标 性能测试通常需要监控的指标包括: 1.服务器Linux(包括CPU.Memory.Load.I/O). 2.数据库:1.Mysql 2.Oracle(缓存命中.索引.单条SQL性能.数据库[/url]线程数.数据池连接数). 3.中间件:1.Jboss 2. Apache(包括线程数.连接数.日志). 4.网络: 吞吐量.吞吐率. 5.应用: jvm内存.日志.Full GC频率. 6.监控工具(LoadRunner[/url]):用户执行情况.场景状态.事务响应时间.TPS等. 7.

淘宝性能测试要点

每台服务器每秒平均PV量= ( (80%*总PV)/(24*60*60*(9/24)))/服务器数量,即每台服务器每秒平均PV量=2.14*(总PV)/* (24*60*60) /服务器数量最高峰的pv量是1.29倍的平均pv值 性能测试策略:1.模拟生产线真实的硬件环境.2.服务器置于同一机房,最大限度避免网络问题.3.以PV为切入点,通过模型将其转换成性能测试可量化的TPS.4.性能测试数据分为基础数据和业务数据两部分,索引和SQL都会被测试到.5.日志等级设置成warn,避免大量打印log