请教个 jvm 参数调优的问题

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

已注册用户请登录

这是一个创建于 2782 天前的主题，其中的信息可能已经有所发展或是发生改变。

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 和内存的利用率都处在比较低的水平上。这种是啥原因呢?

log

jvm

机器

内存

19 条回复 2018-09-12 15:59:20 +08:00

GavinChou

2018 年 9 月 11 日

12g 是堆可以申请到的内存，但是未必一定能申请到的。服务器 16g 内存，不光运行你的服务，如果其它服务占用了一定内存，使得 jvm 堆没法申请到 12g 内存，就会出现只能用到 6g 到头的情况。至于卡顿的情况，可能有其他原因，是否卡顿最好是通过稍微细粒度的监控判断，前台用户感受的粒度有点粗，不好定位问题，而且也要看 cpu 负载。

szq8014

2018 年 9 月 11 日

1. 看 GClog 你这 GC 也不慢，卡顿是不是其它组件导致的，数据库？
2. 线程数多的话 XSS 也可以调调，调成够用的前提下尽量小

话说，-Xmn5g -XX:MaxNewSize=1024m 是啥情况？

你可以把 gc log 发上来让大家看看，或许发现更多的问题

bk201

2018 年 9 月 11 日

网络延迟考虑过么.

thisisgpy

2018 年 9 月 11 日

我觉得你可能需要 xxfox.perfma.com 这个神器，欢迎使用。

CoderGeek

2018 年 9 月 11 日

用更具体的监控工具查看一下。

linshuang

2018 年 9 月 11 日

堆给了 12g，新生代给了 5g，那么老年代有 6g 多，比官方的比例少了些，不过你说 full gc 毫秒级别，结果导向论来说反倒是没问题。至于内存没用满，这个不好下断言，也可能在这种压力下你网络带宽就只能吃掉这些，然后卡住了转到应用层。最后说卡顿，看看系统的其它部分有无限制。

ps -Xmn5g -XX:MaxNewSize=1024m 后面这项应该是多余的。

no13bus

2018 年 9 月 11 日

@GavinChou cpu 负载的话不高。20-30%左右的吧。

no13bus

2018 年 9 月 11 日

@linshuang
@szq8014
@GavinChou
jstack 看了下，发现高峰的时候大概 3k 多 blocked 状态的线程，不过没有死锁。因为程序涉及到将用户的头像上传到七牛云上。用户的七牛的官方 sdk。
流程就是：
用户认证--获取头像---上传七牛--返回前台 ok 这是个同步的过程。是不是因为这个和七牛的阻塞交互造成的？

q397064399

2018 年 9 月 11 日

@no13bus #8 拆分下吧，这些 IO 密集型吃线程的拆分到对应的服务上

no13bus

2018 年 9 月 11 日

@thisisgpy 好棒

linshuang

2018 年 9 月 11 日

@no13bus 用队列把这步上传图片到七牛这块交给别的机器来处理，快速响应。另外考虑下上传七牛这一步会占多少公网的带宽。最后，你这个系统需求挺奇特，怎么会总是需要在高峰传头像？

no13bus

2018 年 9 月 11 日

@linshuang 不是这个意思，上传图像是一直存在的动作，不管是高峰还是低峰，来了个用户就会在刚进入的时候这么干。这个异步上传的功能已经开始做了。
带宽的话这个再看看。
多谢啦。

ghos

2018 年 9 月 11 日

可以试试做把文件的上传独立出来,做成异步的,在加上限流应该差不多了吧

Raymon111111

2018 年 9 月 11 日

先想办法找到卡顿的原因

xiaoshenke

2018 年 9 月 12 日 via Android

同步转异步解决线程爆炸问题

no13bus

2018 年 9 月 12 日

@xiaoshenke 用 root 账户启动的，线程数还是够的，如果不够的话就直接 oom 了。

micean

2018 年 9 月 12 日

肯定是 io 多了，线程数不够，不是 gc 的原因
还是用 nio 模型吧，只要不涉及到 jdbc 的都可以做成异步的

GavinChou

2018 年 9 月 12 日

@no13bus 3k+ 虽然没有 OOM，但是线程 block 本身不是一个好现象，正像其他朋友回复那样，要么修改这个同步的流程，对服务做拆分，要么改成异步的方式解决网络 IO 阻塞的问题。线程多了线程切换的开销也会很大，所以一般就线程池 + 队列 / NIO，推荐 NIO 模型，如果同步的方式做限流，性能上不如 NIO 那么好啊

no13bus

2018 年 9 月 12 日

嗯嗯。用的 springboot。用队列搞了。
@GavinChou