移动专线维护系统3_项目压力测试、JVM内存情况分析

一、说明

服务器参数

• 服务器1：2核2G CentOS7 带宽 1M
• 服务器2：2核2G Alibaba Cloud Linux 2.1903 LTS 64位带 宽 1M

内存、CPU使用情况

二、测试内容

1、Nginx服务器压测

首先docker stats 打开监控

Nginx压测1：100个线程，压测2分钟

Nginx压测1 结果分析

Nginx压测2：1000个线程，压测1分钟

Nginx压测结果图表

线程数量	压测时间	异常	吞吐量	总样本	90%请求响应时间（没超过这个时间）	99%响应时间
100	2分钟	0.42%	200/s	23000	900	1400
1000	1分钟	8.35%	200/s	12000	8900	59000

2、网关模块压测

说明

网关服务启动的参数 -Xmx128M
测试的网关路由功能通过xxx:端口?api/qq?xiaosi 跳转到qq.com的页面的过程可能会存在网络误差，并不是直接转发到注册中心的服务，仅供参考

网关模块压测1：10个线程，压测1分钟

网关模块压测2：50个线程，压测1分钟

网关模块压测3：100个线程，压测1分钟

注意：前两次的异常测试不太准确，未正确停止线程直接点击的stop，第4次服务器直接崩了…

网关模块压测结果图表

线程数量	压测时间	异常	吞吐量	总样本	90%请求响应时间（没超过这个时间）	99%响应时间
10	1分钟	4.76%	3.4/s（不准确）	210	3071	4959
50	1分钟	4.55%	20/s（不准确）	1100	2946	3089
100	1分钟	0.0%	33/s	2204	2991	3293

3、Nginx 、网关联合压测

开了1000个线程，服务器内存扛不住了，服务器已崩…有时间在测
第二天重启之后测试，所测结果以图表的形式展现

测试中的系统资源占用

Nginx、网关联合压测1：50个线程，压测1分钟

Nginx、网关联合压测2：100个线程，压测1分钟

联合压测结果图标

线程数量	压测时间	异常	吞吐量	总样本	90%请求响应时间（没超过这个时间）	99%响应时间
50	1分钟	0.0%	15.2s	-	3000	6000
100	1分钟	0.0%	32.6s	-	3000	3200

三、所有压测结果对比

压测内容	线程数量	压测时间	异常	吞吐量	总样本	90%请求响应时间（没超过这个时间）	99%响应时间
Nginx	100	2分钟	0.0%	200/s	23000	900	1400
网关	100	1分钟	0.0%	33s	-	3000	3200
网关+Nginx	100	1分钟	0.0%	32.6s	2100	3000	3200

分析

• 1、联合压测和单独压测网关的性能相差较小，包括吞吐量和响应时间，和单独压测Nginx的性能相差较大，可以看出来主要性能瓶颈就是网关
• 2、另外随着压测，发现网关服务所占内存在逐渐增大

分析JVM进程占用内存情况

1、网关服务：启动设置的-Xmx128M，即堆内存最大为128M。实际内存大约占了369M

2、admin模块：启动设置的-Xmx200M，即堆内存最大为200M。实际内存大约占了402M

追踪JVM内存GC情况

常用命令

• jps : 查看所有的JVM进程
• jstack pid ：该进程的线程信息，可以检测是否发生死锁（stack -l pid,-l参数可以打印出锁的相关信息）
• jmap -heap pid :该进程的内存占用信息
• jstat -gc pid 打印时间：打印该进程的内存信息（新生代、老年代），或者jstat -gccause pid 可以查看百分比

以网关JVM内存为例

参数说明

可以看出网关服务的

• 老年代内存占用为 92204 / 108544 ，可以看出几乎要占满了，方法区占用64M / 66M，另外还有一些类库函数啥的（包括是Thread Stack，因为压测会产生大量线程），压测过程主要发生YongGC共93次，没有发生FullGC。加起来内存大约为369M
  

• 另外发现即使jstat显示的全部内存加起来不够实际占用的，为什么实际占用这么多？解答参考：https://www.cxybb.com/article/w1014074794/113340344