jmeter-性能调优

前提：

        1、当CPU、内存和硬盘的使用率非常低，就要从软件找原因；

        2、当CPU和硬盘的使用率低，内存的使用率非常高，就要从软件是否存在内存泄漏找原因；

        3、当CPU、内存和硬盘的使用率非常高，消息队列开始堆积，证明硬件使用率达到最高；

一、linux

1.磁盘

2.CPU和内存

3.网络

        用内网压测，减少其他带宽影响压测结果

4.连接数，附上我在虚拟机上做的系统优化。

# cat /etc/sysctl.conf 
# sysctl settings are defined through files in
# /usr/lib/sysctl.d/, /run/sysctl.d/, and /etc/sysctl.d/.
#
# Vendors settings live in /usr/lib/sysctl.d/.
# To override a whole file, create a new file with the same in
# /etc/sysctl.d/ and put new settings there. To override
# only specific settings, add a file with a lexically later
# name in /etc/sysctl.d/ and put new settings there.
#
# For more information, see sysctl.conf(5) and sysctl.d(5).
net.ipv4.tcp_syncookies = 0
fs.file-max = 12553500
fs.nr_open = 12453500
kernel.shmall= 1048576
kernel.shmmax = 1887436
kernel.msgmax = 65536
kernel.sysrq = 0
kernel.pid_max= 65536
net.core.netdev_max_backlog = 2000000
net.core.rmem_default = 699040
net.core.rmem_max = 50331648
net.core.wmem_default = 131072
net.core.wmem_max = 33554432
net.core.somaxconn = 65535
net.ipv4.ip_nonlocal_bind = 1
net.ipv4.tcp_max_orphans = 3276800
net.ipv4.tcp_mem = 1048576 1572864 2097152
net.ipv4.tcp_rmem = 4096 4194304 8388608
net.ipv4.tcp_wmem = 4096 4194304 8388608
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_window_scaling = 1
vm.swappiness = 0

#TCP connection recovery
net.ipv4.tcp_max_tw_buckets = 6000000
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 10
net.ipv4.route.max_size = 5242880
net.ipv4.ip_forward = 1
net.ipv4.tcp_timestamps = 1
#开启对于TCP时间戳的支持,若该项设置为0，则下面一项设置不起作用

#TCP connection manager
net.ipv4.tcp_max_syn_backlog = 655360
net.ipv4.tcp_syn_retries = 6
net.ipv4.tcp_retries1 = 3
net.ipv4.tcp_retries2 = 6

#TCP keepalive
net.ipv4.ip_local_port_range = 1025 65534
net.ipv4.tcp_keepalive_time = 30
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 3

文件打开数优化
# cat /etc/security/limits.conf
root soft nofile 1024000
root hard nofile 1024000

5.设置jvm内存

找到JMeter bin目录下的jmeter.bat文件，notepad等文本工具打开，编辑找到如下内容：

　　rem See the unix startup file for the rationale of the following parameters,
　　rem including some tuning recommendations
　　set HEAP=-Xms512m -Xmx512m
　　set NEW=-XX:NewSize=128m -XX:MaxNewSize=128m
　　set SURVIVOR=-XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=50%
　　set TENURING=-XX:MaxTenuringThreshold=2

修改带背景色，文字带颜色内容如下：

　　set HEAP=-Xms2048m -Xmx2048m
　　set NEW=-XX:NewSize=640m -XX:MaxNewSize=640m

说明：
　　-Xms512m：初始化堆内存大小 -Xmx512m：最大堆内存大小，这里的内存大小建议为512的整数倍，可以根据机器实际内存进行合理的设置，建议最大值-Xmx不要超过剩余物理内存的50%。　
　　通常会将 -Xms 与 -Xmx两个参数的配置相同的值，其目的是为了能够在java垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小而浪费资源。
　　set NEW=-XX:NewSize=640m -XX:MaxNewSize=640m
　　-XX:newSize：新生代初始内存的大小，应该小于 -Xms的值
　　-XX:MaxnewSize：表示新生代可被分配的内存的最大上限；当然这个值应该小于-Xmx的值，因为新生代占内存来自整个堆内存。为了优化GC(内存垃圾回收)，最好设置-XX:MaxnewSize值约等于-Xmx的1/3　　
　　注意：jvm在执行GC时，会停止工作。MaxnewSize的增大，可以降低GC频率。　

二、中间件 数据库mysql，消息队列mq

1.数据库加索引

2. com.mysql.jdbc.JDBC4Connection 数据库连接池，连接数太低

3.优化慢sql，数据库慢查询

大部分系统都会用到数据库，而数据库的操作往往是涉及到磁盘 I/O 的读写。大量的数据库读写操作，会导致磁盘 I/O 性能瓶颈，进而导致数据库操作的延迟性。对于有大量数据库读写操作的系统来说，数据库的性能优化是整个系统的核心。

在PostgreSQL中，带子查询的复杂SQL语句，如果用LIMIT和OFFSET进行分页，有很大概率会出现慢查询。

(1)追踪慢sql

如果活跃连接数的变化处于正常范围，则很大概率可能是当时有性能很差的SQL被大量执行导致。我们可以通过这个日志，定位到当时比较耗时的SQL来进一步做分析。但通常问题发生时，整个系统都处于停滞状态，所有SQL都慢下来，当时记录的>慢SQL可能非常多，并不容易排查罪魁祸首。这里我们介绍几种在问题发生时，即介入追查慢SQL的方法。

1)直接通过pg_stat_activity视图

--查询执行时间超过1秒的sql

select * from pg_stat_activity where state<>'idle' and now()-query_start > interval '1 s' order by query_start ; 

-- 查询时间较长的SQL,idle :是空闲的;client backend:客户端请求后端

select pid,xact_start,now()-xact_start as t ,state,query,client_addr,datname,backend_type from pg_stat_activity where state <>'idle' and backend_type='client backend' and now()-query_start > interval '0.1 s'  order by t desc limit 5;

2)从数据表上表扫描（Table Scan）的信息开始查起，查找缺失索引的表。数据表如果缺失索引，大部分热数据又都在内存时（例如内存8G，热数据6G），此时数据库只能使用表扫描，并需要处理已在内存中的大量的无关记录，而耗费大量CPU。特别是对于表记录数超100的表，一次表扫描占用大量CPU（基本把一个CPU占满），多个连接并发（例如上百连接），把所有CPU占满。

--查出使用表扫描最多的表（疯狂读写）

select * from pg_stat_user_tables where n_live_tup > 100000 and seq_scan > 0 order by seq_tup_read desc limit 10;

3)锁

-- 查询已经锁住的SQL

select *, now()-xact_start as t from pg_stat_activity where  state='active' and wait_event_type like '%Lock%';

-- 查询锁表的SQL

select * from pg_stat_activity where wait_event_type like '%Lock%'

(2)优化sql（了解）

1)对查询涉及的表，执行ANALYZE <table>或VACUUM ANZLYZE <table>，更新表的统计信息，使查询计划更准确。注意，为避免对业务影响，最好在业务低峰执行。

2)执行explain (query text)或explain (buffers true, analyze true, verbose true) (query text)命令，查看SQL的执行计划（注意，前者不会实际执行SQL，后者会实际执行而且能得到详细的执行信息），对其中的Table Scan涉及的表，建立索引。

3)重新编写SQL，去除掉不必要的子查询、改写UNION ALL、使用JOIN CLAUSE固定连接顺序等到，都是进一步深度优化SQL的手段，这里不再深入说明。

三、jmeter

1.修改Jmeter.bat文件，调整JVM参数，将heap和permsize值适当的设置大一点，java虚拟机的内存配置

        调整JMeter堆栈内存大小 有两个JAVA的参数直接影响着JMeter能够使用的系统内存为多少，一个是“Xms”（代表初始化堆栈内存的大小），一个是“Xmx（代表最大内存池可以分配的大小）”。如果你的测试机器只跑JMeter一个JAVA应用程序，那么建议Xmx和Xms保持一致。Xmx和Xms保持一致是为了减少JVM内存伸缩，减少维护伸缩带来的成本。

2.联机负载，减少单台机器上的负载线程数，不要使用分布式，使用多台机器，单点jmeter　　

3.采用命令模式运行测试

        GUI在一定程度上冻结并消耗资源，这样会更容易产生一些不准确的性能测试结果。 对于JMeter来说GUI存在的意义主要在于可视化输出结果，编写你的测试计划和debug你的测试计划。

4.减少日志打印，降低io读写的消耗

5.压测过程中禁用监听器

6.谨慎使用断言

        添加到测试计划的每个测试元素都将被处理。这样会占用较多的CPU和内存。这种资源的占用适用于所有的断言，尤其是比较断言。比较断言消耗大量资源和内存，所以在压力测试时慎重的使用断言和断言的数量，尽可能少的使用断言。

 

四、主程序java+python

1.java虚拟机的内存配置