请教个 jvm 参数调优的问题

2018-09-11 14:39:42 +08:00
 no13bus
jvm 参数如下:

-server -Xms12g -Xmx12g -Xmn5g -XX:MaxNewSize=1024m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+DisableExplicitGC -XX:+CMSParallelRemarkEnabled -XX:+PrintGCDetails -XX:+PrintGCDateStamps -verbose:gc -Xloggc:./minigc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./dump.log -XX:ErrorFile=./jvm-crash.log

机器的配置:
阿里云机器 1 个 slb 后面挂了 8 台机器 每个机器的配置都是 16G 内存


线上的 gc 情况:
YGC 的话平均一次 15.79ms
FGC 的话也不是很频繁 一小时一次吧, 每次的时间也是 ms 级别


问题:
高峰期的时候,qps 大概是 3000-4000 左右吧
高峰的时候发现虽然我设置了 12G 但是只能用到 6G 就到头了,内存再也涨不上去了。但是前台用户那里的话发现会出现有卡顿的情况. 然后发现 cpu 和内存的利用率都处在比较低的水平上。这种是啥原因呢?
3281 次点击
所在节点    Java
19 条回复
GavinChou
2018-09-11 15:00:06 +08:00
12g 是堆可以申请到的内存,但是未必一定能申请到的。服务器 16g 内存,不光运行你的服务,如果其它服务占用了一定内存,使得 jvm 堆没法申请到 12g 内存,就会出现只能用到 6g 到头的情况。至于卡顿的情况,可能有其他原因,是否卡顿最好是通过稍微细粒度的监控判断,前台用户感受的粒度有点粗,不好定位问题,而且也要看 cpu 负载。
szq8014
2018-09-11 15:28:13 +08:00
1. 看 GClog 你这 GC 也不慢,卡顿是不是其它组件导致的,数据库?
2. 线程数多的话 XSS 也可以调调,调成够用的前提下尽量小

话说,-Xmn5g -XX:MaxNewSize=1024m 是啥情况?

你可以把 gc log 发上来让大家看看,或许发现更多的问题
bk201
2018-09-11 15:39:05 +08:00
网络延迟考虑过么.
thisisgpy
2018-09-11 15:55:41 +08:00
我觉得你可能需要 xxfox.perfma.com 这个神器,欢迎使用。
CoderGeek
2018-09-11 15:58:06 +08:00
用更具体的监控工具查看一下。
linshuang
2018-09-11 16:23:54 +08:00
堆给了 12g,新生代给了 5g,那么老年代有 6g 多,比官方的比例少了些,不过你说 full gc 毫秒级别,结果导向论来说反倒是没问题。至于内存没用满,这个不好下断言,也可能在这种压力下你网络带宽就只能吃掉这些,然后卡住了转到应用层。最后说卡顿,看看系统的其它部分有无限制。

ps -Xmn5g -XX:MaxNewSize=1024m 后面这项应该是多余的。
no13bus
2018-09-11 17:50:15 +08:00
@GavinChou cpu 负载的话不高。20-30%左右的吧。
no13bus
2018-09-11 17:54:16 +08:00
@linshuang
@szq8014
@GavinChou
jstack 看了下,发现高峰的时候大概 3k 多 blocked 状态的线程,不过没有死锁。因为程序涉及到将用户的头像上传到七牛云上。用户的七牛的官方 sdk。
流程就是:
用户认证--获取头像---上传七牛--返回前台 ok 这是个同步的过程。是不是因为这个和七牛的阻塞交互造成的?
q397064399
2018-09-11 17:58:26 +08:00
@no13bus #8 拆分下吧,这些 IO 密集型 吃线程的 拆分到对应的服务上
no13bus
2018-09-11 18:05:33 +08:00
@thisisgpy 好棒
linshuang
2018-09-11 18:43:38 +08:00
@no13bus 用队列把这步上传图片到七牛这块交给别的机器来处理,快速响应。另外考虑下上传七牛这一步会占多少公网的带宽。最后,你这个系统需求挺奇特,怎么会总是需要在高峰传头像?
no13bus
2018-09-11 22:56:07 +08:00
@linshuang 不是这个意思,上传图像是一直存在的动作,不管是高峰还是低峰,来了个用户就会在刚进入的时候这么干。这个异步上传的功能已经开始做了。
带宽的话这个再看看。
多谢啦。
ghos
2018-09-11 23:25:38 +08:00
可以试试做把文件的上传独立出来,做成异步的,在加上限流应该差不多了吧
Raymon111111
2018-09-11 23:33:42 +08:00
先想办法找到卡顿的原因
xiaoshenke
2018-09-12 00:24:43 +08:00
同步转异步解决线程爆炸问题
no13bus
2018-09-12 07:40:58 +08:00
@xiaoshenke 用 root 账户启动的,线程数还是够的,如果不够的话就直接 oom 了。
micean
2018-09-12 09:41:36 +08:00
肯定是 io 多了,线程数不够,不是 gc 的原因
还是用 nio 模型吧,只要不涉及到 jdbc 的都可以做成异步的
GavinChou
2018-09-12 14:36:45 +08:00
@no13bus 3k+ 虽然没有 OOM,但是线程 block 本身不是一个好现象,正像其他朋友回复那样,要么修改这个同步的流程,对服务做拆分,要么改成异步的方式解决网络 IO 阻塞的问题。线程多了线程切换的开销也会很大,所以一般就线程池 + 队列 / NIO,推荐 NIO 模型,如果同步的方式做限流,性能上不如 NIO 那么好啊
no13bus
2018-09-12 15:59:20 +08:00
嗯嗯。用的 springboot。用队列搞了。
@GavinChou

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/488196

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX