首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
宝塔
V2EX  ›  Java

请教个 jvm 参数调优的问题

  •  
  •   no13bus · 2018-09-11 14:39:42 +08:00 · 2116 次点击
    这是一个创建于 435 天前的主题,其中的信息可能已经有所发展或是发生改变。
    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 和内存的利用率都处在比较低的水平上。这种是啥原因呢?
    19 回复  |  直到 2018-09-12 15:59:20 +08:00
        1
    GavinChou   2018-09-11 15:00:06 +08:00
    12g 是堆可以申请到的内存,但是未必一定能申请到的。服务器 16g 内存,不光运行你的服务,如果其它服务占用了一定内存,使得 jvm 堆没法申请到 12g 内存,就会出现只能用到 6g 到头的情况。至于卡顿的情况,可能有其他原因,是否卡顿最好是通过稍微细粒度的监控判断,前台用户感受的粒度有点粗,不好定位问题,而且也要看 cpu 负载。
        2
    szq8014   2018-09-11 15:28:13 +08:00
    1. 看 GClog 你这 GC 也不慢,卡顿是不是其它组件导致的,数据库?
    2. 线程数多的话 XSS 也可以调调,调成够用的前提下尽量小

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

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

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