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 后面这项应该是多余的。 |
8
no13bus OP |
9
q397064399 2018-09-11 17:58:26 +08:00
@no13bus #8 拆分下吧,这些 IO 密集型 吃线程的 拆分到对应的服务上
|
11
linshuang 2018-09-11 18:43:38 +08:00
@no13bus 用队列把这步上传图片到七牛这块交给别的机器来处理,快速响应。另外考虑下上传七牛这一步会占多少公网的带宽。最后,你这个系统需求挺奇特,怎么会总是需要在高峰传头像?
|
12
no13bus OP |
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 OP @xiaoshenke 用 root 账户启动的,线程数还是够的,如果不够的话就直接 oom 了。
|
17
micean 2018-09-12 09:41:36 +08:00 1
肯定是 io 多了,线程数不够,不是 gc 的原因
还是用 nio 模型吧,只要不涉及到 jdbc 的都可以做成异步的 |