性能笔记

评估并发用户数：
线上系统:在线上系统的高峰时刻，选取一定周期内使用系统的人数，这些人数可以认为是在线用户数。而并发用户 数则取在线用户数的10%。例如，在1小时内使用系统的用户数为10000，则建议取1000作为并发用户 数。
未上线系统或新上线系统。 由于没有历史数据可供参考，因此只能通过业务发展趋势来预判各项指标。
评估TPS（RPS）：
线上系统。 已有系统：可选取高峰时刻，在一定时间内（如3分钟~10分钟），获取系统总业务量，计算单位时间 （秒）内完成的笔数，乘以2~5倍作为峰值的TPS，例如峰值3分钟内处理订单18万笔，平均TPS是 1000，峰值TPS可以是2000~5000。
未上线系统或新上线系统。 由于没有历史数据可供参考，因此只能通过业务发展趋势来预判各项指标。

 

基准测试
系统无压力下，单用户迭代执行连续时间或次数，取得事务平均响应时间，作为分析衡量的标准。
单交易并发测试
单场景下的多并发测试，检测系统多并发情况下服务器硬件资源利用情况，网络，应用等情况。同时也检查系统服务器是否健壮。
容量测试
测出系统的最大容量。通过不断调整负载，找出系统在满足性能指标条件下的最优容量，此配置下系统的最大并发数。
混合测试
混合场景测试，对典型脚本按照一定比例组成的混合脚本
稳定性测试
模拟一定数量用户长时间运行，验证系统在长时间运行后用户对系统的访问操作成功率是否降低，以找出系统潜在的内存泄漏问题。
浪涌测试
高强度和低负载的交叉压力测试，验证两种情况下的稳定性，以找出在增加和减少负载的过程中由于突然的占用和释放系统资源引起的问题。

通过测试左移的技术去支撑研发的质量改进，通过测试右移支撑DevOps的平稳运行，通过质量监控支撑产品与运营能力。
逐层分析，缩小问题范围

#关闭网络防火墙
root@kerneltalks # iptables -F
root@kerneltalks # iptables -X
root@kerneltalks # iptables -P INPUT ACCEPT
root@kerneltalks # iptables -P OUTPUT ACCEPT
root@kerneltalks # iptables -P FORWARD ACCEPT
iptables -L 查看

查看所有进程占用的文件句柄数：
lsof -n|awk '{print $2}'|sort|uniq -c |sort -nr|wc -l
统计所有java进程占用的文件句柄数
lsof -n|awk '{print $2}'|grep -E "`ps -ef|grep java | grep -v grep | awk '{print $2}'`"|sort|uniq -c |sort -nr|wc -l
找出大于1G的文件目录
find / -type f -size +1G -exec du -h {} \;

-------------JMX远程监控配置
-Dcom.sun.management.jmxremote.port=2099 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Djava.rmi.server.hostname=172.17.2.89"

----------------mysql
在一个page里面依然会导致热page

数据块
文件存储在硬盘上，硬盘的最小存储单元是扇区(sector)，每个扇区存储512字节也就是0.5KB。
操作系统读取硬盘数据时，并非一次读取一个扇区，为提高效率，一次性连续读多个扇区，一般是8个扇区，这些同次性被读出的扇区组成块，常见块大小为4KB。

yum install perf -y
perf top -a -g -p `pidof mysqld`
perf record -F 99 -a -g -p `pidof mysqld` -- sleep 60
perf report -g -i perf.data
perf report -g -i perf.data --stdio >jieguo.txt

perf record -a -e cycles -o /tmp/collect/perf_cycle.perf -g sleep 120
perf script -i /tmp/collect/perf_cycle.perf &> /tmp/collect/perf.unfold

---------------------------------网络连接状态
windows netstat -an | find "ESTABLISHED" /c
Linux
nginx代理服务器对外提供的端口就是80和443，所以我们针对"TIME-WAIT"状态来进行过滤本地地址和端口而且通过-w进行严格匹配2个条件就是"192.168.71.101:80|192.168.71.101:443"，这样就统计出Nginx作为服务器一方的外连TIME-WAIT的数量。
ss -nat | grep "TIME-WAIT" | awk '{print $4}' | egrep -w "nginxIP:80|nginxIP:443" | wc -l
增加一个-v参数来取反，这样就获取了本地地址中不是80和443端口的TIME-WAIT状态数量，那么这个数量就是Nginx作为客户端进行内连后端服务器所产生的。
ss -nat | grep "TIME-WAIT" | awk '{print $4}' | egrep -w -v "192.168.71.101:80|192.168.71.101:443" | wc -l

netstat -s | egrep "listen|LISTEN"
netstat -an|awk '/^tcp/{++S[$NF]}END{for (a in S)print a,S[a]}'

#根据ip分组
netstat -na|grep ESTABLISHED|awk '{print $5}'|awk -F: '{print $1}'|sort -nr|uniq -c

cat /proc/sys/net/ipv4/ip_local_port_range

#进程打开线程数
pstree -p 进程号 | wc -l

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'|egrep 'ESTABLISHED'|awk '{print $2}'

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

netstat -nat|grep -i 9100|grep TIME_WAIT|wc -l

查看 tomcat 连接 oracle 数据库的连接池。
netstat -an | grep 数据库端口 | awk '{print $(NF-1)}'|sort | uniq -c

------------------内核参数调整------------------------------
centos 内核参数调整 vim /etc/sysctl.conf

# #修改消息队列长度
kernel.msgmnb = 65536
kernel.msgmax = 65536

# #timewait的数量，默认180000
net.ipv4.tcp_max_tw_buckets = 6000
# #允许系统打开的端口范围
net.ipv4.ip_local_port_range = 1024 65000
cat /proc/sys/net/ipv4/ip_local_port_range

cat /proc/sys/vm/swappiness
/etc/sysctl.conf vm.swappiness=0
swappiness=0的时候表示最大限度使用物理内存
---------------------------TIME_WAIT----------
主动断开的一方的TCP连接会在TIME_WAIT这个状态下保持2MSL，其作用就2个：
1.确保对方收到自己发送的最后一个ACK（因为对方发送了FIN），如果对方没有收到自己发送的ACK必定会重新发送FIN，这样保证4次断开的完整性。因为MSL是最大报文生存时间，
如果在1个MSL时间内自己发送的ACK对方没有收到那就注定收不到了，而且对方肯定还会发送FIN，那么一个FIN发送过来的最长时间也是1个MSL，所以这里要等待2MSL。
2.另外一个原因就是避免延迟的IP报文，在频繁短连接的场景下客户端通常会对同一个IP和端口在短时间内发起多次连接，而客户端使用的端口是自己系统随机分配的高位端口，
有一定概率发生上一个socket四元组和下一个socket四元组一样，如果这时候一个原本属于上一个socket四元组的被延迟的IP报文送达，那么这将发送数据混乱的状态，
所以为了避免这种情况就利用MSL这个报文最大生存时长机制让残余的IP报文在网络中消失。这时候同样的四元组又可以被使用了。

vi sysctl.conf
#表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；
net.ipv4.tcp_syncookies=1
# 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_reuse = 1
# 修改tcp会话进去fin状态后的等待时间，超时则关闭会话
net.ipv4.tcp_fin_timeout=30
net.ipv4.ip_local_port_range = 1024 65000

/sbin/sysctl -p

# 处于TIME_WAIT最大的socket数量，默认为180 000，超过这个数目处于TIME_WAIT的socket立即被清除
net.ipv4.tcp_max_tw_buckets=180000
-----------------------------------------------nginx 相关参数调整

#工作进程调大
worker_processes 2;
#指定不同核
worker_cpu_affinity 00000001 00000010;
worker_rlimit_nofile 20480;

events {
use epoll;
worker_connections 20480;
}

client->nginx->server
默认情况下，Nginx已经自动开启了对 Client 连接的 keepalive 支持 客户端连接ngnix，nginx主动关闭连接出现TIME_WAIT
客户端在Keep-alive超时内没有进行通信那么当触发超时时服务器就会主动断开连接，
另外一个情况就是Nginx设置对Keep-alive最大请求数量，意思是改链接在复用的时候可以发送多少次请求，如果到达这个最大请求次数也会断开连接，但无论怎么说这种情况是服务器主动断开所以TIME_WAIT则会出现在服务器上。
client->nginx的TIME_WAIT
ss -nat | grep "TIME-WAIT" | awk '{print $4}' | egrep -w "nginxIP:80|nginxIP:443" | wc -l

nginx->server的TIME_WAIT
ss -nat | grep "TIME-WAIT" | awk '{print $4}' | egrep -w -v "192.168.71.101:80|192.168.71.101:443" | wc -l

http {
keepalive_timeout 120s; #客户端链接超时时间。为0的时候禁用长连接。即长连接的timeout
keepalive_requests 10000; #在一个长连接上可以服务的最大请求数目。当达到最大请求数目且所有已有请求结束后，连接被关闭。默认值为100。即每个连接的最大请求数
}
------------------------------------------awr-----------------------------
sqlplus / as sysdba
exec dbms_workload_repository.create_snapshot;

Load Profile
Redo size:每秒产生的日志大小(单位字节)，可标志数据变更频率, 数据库任务的繁重与否。
Logical reads:平决每秒产生的逻辑读的block数。Logical Reads= Consistent Gets + DB
Block Gets
Block changes:每秒block变化数量，数据库事物带来改变的块数量。
Physical reads:平均每秒数据库从磁盘读取的block数。
Physical writes:平均每秒数据库写磁盘的block数。
User calls:每秒用户调用次数。
Parses:每秒解析次数，包括fast parse，soft parse和hard parse三种数量的综合。软解
析每秒超过300次意味着你的"应用程序"效率不高，调整session_cursor_cache。在这里，
fast parse指的是直接在PGA中命中的情况（设置了session_cached_cursors=n）；soft parse
是指在shared pool中命中的情形；hard parse则是指都不命中的情况。
Hard parses:每秒产生的硬解析次数, 每秒超过100次，就可能说明你绑定使用的不好，也
可能是共享池设置不合理。这时候可以启用参数cursor_sharing=similar|force，该参数默
认值为exact。但该参数设置为similar时，存在bug，可能导致执行计划的不优。
Sorts:每秒产生的排序次数。
Logons:每秒登陆的次数。
Executes:每秒执行次数。
Transactions:每秒产生的事务数，反映数据库任务繁重与否。

===================================FULL GC 出现的几种情况==================
1. System.gc()方法的调用
2. 老年代代空间不足
3. 永久区空间不足
4. CMS GC 时出现 promotion failed 和 concurrent mode failure。
说明：对于采用 CMS 进行老年代 GC 的程序而言，尤其要注意 GC 日志中是否有 promotion failed 和 concurrent mode
failure 两种状况。
5. 统计得到的 Minor GC 晋升到老年代的平均大小大于老年代的剩余空间
6. 堆中分配很大的对象
说明：大对象，是指需要大量连续内存空间的 java 对象，例如很长的数组。老年代虽然有很大的剩余空间，
但是无法找到足够大的连续空间来分配给当前对象，此种情况就会触发 JVM 进行 Full GC。一般使用
-XX:+UseCMSCompactAtFullCollection 和 -XX:CMSFullGCsBeforeCompaction 参数结合来解决问题。
7. NIO 使用 DirectBuffer 分配物理内存，空间不足。
说明：当 DirectBuffer 占用内存空间不足时，会显示调用 system.gc()，主动触发 fullgc。所以对于 NIO 的应用建
议不要在 JVM 启动参数中追加-XX:+ DisableExplicitGC，否则会出现 DirectBuffer oom。

CMS 常用参数
-XX:+UseConcMarkSweepGC 启用 CMS。
-XX:+UseCMSCompactAtFullCollection 在 full gc 的时候，对 old 区压缩。
-XX:+CMSScavengeBeforeRemark 这个参数还重要的，它的意思是在执行 CMS
remark 之前进行一次 youngGC，这样能有效降低 remark 的时间，之前没有加这
个参数，remark 时间最大能达到 3s，加上这个参数之后 remark 时间减少到 1s
之内。但是 remark 之后也将立即开始又一次 minor gc。
-XX:CMSFullGCsBeforeCompaction=1 多少次 full gc 后进行 old 区压缩，cms
会产生 old 区"碎片"，要进行整理，避免没有连续空间放大对象而引发 cms failure
出现。
-XX:CMSInitiatingOccupancyFraction=70 old 区使用 70％后开始 CMS 收集，

-XX:CMSInitiatingPermOccupancyFraction=70 perm 区使用 70％后开始 CMS
收集，

------------------------------
Linux在启动过程中，有三个特殊进程，也就是PID最小的三个进程

0号进程是 idle进程，是系统创建的第一个进程，它在初始化1号和2号进程后，演变为空闲进程，当CPU上没有其他任务执行时，就会运行它
1号进程为init进程，通常是systemd进程，在用户态运行，用来管理其他用户态进程
2号进程为kthreadd进程，在内核态运行，用来管理内核线程

 

-------------jmeter

saveservice.properties 组件名对应的java类名
saveservice类 loadtree()加载jmx文件 loadProperties()加载saveservice.properties

metersphere

使用kafka backend listener将结果、测试日志等信息输送到执行的 Kafka 队列中，
MeterSphere 中的 data-streaming 组件会从 Kafka 中收集这些信息并进行汇总处理，每20s通过generate-report.jar对结果进行聚合计算，结果存入mysql然后 更新到平台的数据看板
jps | grep ApacheJMeter.jar 检查JMeter状态

上传的jmx、csv文件在/test目录，jmeter在/opt