内存
服务器内存资源够用，但是程序性能达到了瓶颈 可疑原因:jvm内存配置太小，没有榨干服务器内存资源。或者是测试场景中的并发量不够。要监控测试过程中，JVM自身的内存是否被用完，如果没用完，就加大并发量)
通过查看JVM的 内存配置，是否用到了 机器的大部分内存
验证:
1.加大并发 -- 排查性能测试并发不够的问题 加大后
2.加大内存 -- 在加大内存之后，性能是否有提升
调jvm内存
-Xms 堆内存最小值 -Xmx 堆内存最大值
java原生命令( springboot ) Tomcat配置（如果是原生tomcat）
直接接在JAVA命令后面，记得 空格 windows 写在 bin 目录 setenw.bat
java -Xmx2G -jar xxx.jar linux 写在 bin 目录 setenv.sh 修改内容用export JAVA_OPTS = "$JAVA_OPTS -Xmx-8g"
cpu
服务器CPU资源够用，但是程序性能达到了瓶颈 可疑原因:程序配置的线程数太少，没有榨干服务器硬件资源。或者是测试场景中的并发量不够
需要线程池的参数来设置线程数
SpringBoot程序 -Dservertomcat.max-threads=100 java -Xmx1200m -jar -Dserver.tomcat.max-threads=100 SNAPSHOT.jar
冷知识 tomcat最大线程数量 200
maxconnections最大连接 acceptCount 没有足够线程处理请求的时候-排队的请求个数 【这两个参数调了没有意义，系统会忽略】
实际垃圾代码情况--》 并发量极少，但是CPU资源占用量大
场景：1.单线程占用CPU 100% (死循环数据太多循环N多次处理 )2.1个请求会导致大量的线程被创建开发人员写业务逻辑代码也用到多线程)
排查使用Arthas 代替jstack看线程到底在干吗
在服务器安装Arthas，在安装目录下运行 ./as.sh 此时会提示当前服务器上运行了哪些程序会让选择 按数字1-2-3.........进行选择
dashboard 整体仪表盘可以看到java的基本情况包括cpu、内存等等
测试关注的主要用法：thread -n 5 展示最忙的前5个线程 显示线程使用的cpu占比【一般在压测试时看一下，是不是哪一个占用了极大的资源，且能定位到代码大概位置处】
MQ测试注意点
异步延时性【日常巡护记录的场景，不在乎返回结果】 异步模式通常用于响应时间敏感业务场景
并发小很快处理完，当并发大的时候，MQ有堆积。此时看延时多久能处理完，看可否接受
数据丢失【注意和上面区分】 此处是巡护和积分两个业务，对积分进行了异步处理 上面是突然大量数据涌进来用的异步
要注意 ，如果发送完毕之后，程序就挂掉了【挂哪个，生产者和消费者都有可能】 ，那么对于数据处理是否存在问题【模拟高并发提交600000条数据，日常巡护完毕后，会有考核系统日常行为分加1】看监控两者是否一致
幂等性 不能重复处理
因为有重试机制，高并发后查看数据？
通过MQ做系统解耦就是分布式架构
那就需要监控多个系统
瓶颈分析
1.资源！！！服务器
2.rocket本身资源监控，关注堆内存 他自己也是java，可以看看jvm之类的【所以还是需要回顾到cpu、内存的方法】
3.看是否有积压---检查 消费者程序的 处理逻辑 或者 消费者程序所在的服务器 资源是否够用--手动增加消费机器，或者需要具体看程序，
