首页   注册   登录

jones

V2EX 第 29487 号会员,加入于 2012-11-08 09:23:13 +08:00
今日活跃度排名 1232
jones 最近回复了
百度云 mac 版客户端确实残废,一直都是这个样子的
虽然是二手的,但起码不是假的,总比某宝某猫全假货强
N+1 赔偿,每个人赔个几十万,值!
@esolve 基本都还在用 CMS,一方面是熟悉这个,另一方面我们的业务对停顿时间敏感,吞吐量的要求不是非常苛刻吞吐量需求只能排在第二位所以对于 G1 还在观望中
@esolve 一般都是先根据硬件情况大致测算出不同堆内存的 Full GC 的停顿时间,一般应用是不允许 GC 停顿超过 1.5 秒,否则就会影响上层业务,在 1.5 秒这个范畴内去设置合理的堆内存,一般硬件上也就三四个 G 的样子, 解决 STW 的问题主要还是靠单机多进程集群的方式,比如你有 32G 的内存可以分配给 JVM 进程,如果你把这些内存一次性分配给一个 JVM 进程,那么一旦产生 FULL GC,应用可能直接停顿半分钟以上甚至一分钟,这绝对是无法接受的,所以通常应该多起几个 JVM 进程,每个进程发生 FULL GC 的时候都要控制在 1.5 秒这个范畴内,这样才不会对上层业务产生影响,开 8 个 JVM 进程每个 4G 内存 1.5 秒 FULL GC 时间明显要比单个进程 32G 内存 1 分钟 FULL GC 好的多,我说的这些都是针对停顿时间敏感的业务比如高并发的 web 应用和 API 服务,如果对停顿时间不敏感也可以只开一个进程,比如后台跑算法啊批处理作业啊爬虫啊什么的就无所谓停顿多长时间了,因为即便是 FULL GC 一次十分钟,我们也是可以接受的
我想问一下,你们开这么大的堆内存,生产环境上有没有实际监控过一次 FULL GC 需要花费的时间呢,恐怕都得以分钟来计吧,难道你们的业务都不需要考虑 STW 的问题?还是除了常用的 CMS 和 G1 收集器外,你们手里还有更吊的垃圾收集器?
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   鸣谢   ·   632 人在线   最高记录 3541   ·  
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.1 · 7ms · UTC 20:24 · PVG 04:24 · LAX 13:24 · JFK 16:24
♥ Do have faith in what you're doing.
沪ICP备16043287号-1