h**********c
发帖数: 4120 | 1 server stop the world 的时候
客户端同步要求怎么处理 |
w**z
发帖数: 8232 | 2 gc stop the world? 那没办法，所有线程都停下。
【在 h**********c 的大作中提到】
: server stop the world 的时候
: 客户端同步要求怎么处理
|
g*****g
发帖数: 34805 | 3 Stop the world是可以通过调GC尽量降低的。另外client应该设置timeout和重试。还
有就是server端是个cluster，只要不用sticky session cookie，request会被load
balancer发给不同结点。不同结点都在stop the world的概率极低。
【在 h**********c 的大作中提到】
: server stop the world 的时候
: 客户端同步要求怎么处理
|
h**********c
发帖数: 4120 | 4 高见，学了，收藏了
【在 g*****g 的大作中提到】
: Stop the world是可以通过调GC尽量降低的。另外client应该设置timeout和重试。还
: 有就是server端是个cluster，只要不用sticky session cookie，request会被load
: balancer发给不同结点。不同结点都在stop the world的概率极低。
|
n*******2
发帖数: 89 | 5 大部分app server 的cluster都是用的sticky session否则同步session信息对网络带
宽性能影响太大
【在 g*****g 的大作中提到】
: Stop the world是可以通过调GC尽量降低的。另外client应该设置timeout和重试。还
: 有就是server端是个cluster，只要不用sticky session cookie，request会被load
: balancer发给不同结点。不同结点都在stop the world的概率极低。
|
g*****g
发帖数: 34805 | 6 这是错的，大型应用通常尽量避免sticky session，因为会带来大量load balancing的
问题。你可以用cookie来存信息，或者使用distributed session store，如memcached
。这样可以保持应用stateless，在scalability上很重要。
【在 n*******2 的大作中提到】
: 大部分app server 的cluster都是用的sticky session否则同步session信息对网络带
: 宽性能影响太大
|
h**********c
发帖数: 4120 | 7 虫老这个贴子是值一千万美刀的
我老良心发现来这问问，cut in五百万
想必有的组，死都不知道死在什么上。
还想吃java 饭，连基本的文档都不看.
memcached
【在 g*****g 的大作中提到】
: 这是错的，大型应用通常尽量避免sticky session，因为会带来大量load balancing的
: 问题。你可以用cookie来存信息，或者使用distributed session store，如memcached
: 。这样可以保持应用stateless，在scalability上很重要。
|
z*******3
发帖数: 13709 | 8 很多时候没办法啊
你看以前dumbcoder就在问那个redis的cluster version
估计就打算解决这个问题，session管理总是一个头疼的问题
能做到stateless固然好，但是很多时候是木有办法呀
memcached
【在 g*****g 的大作中提到】
: 这是错的，大型应用通常尽量避免sticky session，因为会带来大量load balancing的
: 问题。你可以用cookie来存信息，或者使用distributed session store，如memcached
: 。这样可以保持应用stateless，在scalability上很重要。
|
z*******3
发帖数: 13709 | 9 分布式n多个nodes
你不可能所有nodes同时stop the world吧？
另外tune一下jvm
尽量多触发小gc，而不是大gc，这样就可以控制gc时间
还有就是pool object也可以减少这些问题
一般内存中的gc中断不会比你网络上的latency要慢多少
客户端完全没有必要搭理，你ping一下都多少ms了
一般gc也就是ms级的，对于server来说
当然内存大的话，gc停顿也有可能变长
【在 h**********c 的大作中提到】
: server stop the world 的时候
: 客户端同步要求怎么处理
|
z*******3
发帖数: 13709 | 10 是的
jboss和weblogic的default都是如此
所以不太容易很快scale out
现在不都是web嘛，动不动就要爆并发数上去
所以能stateless就statless
【在 n*******2 的大作中提到】
: 大部分app server 的cluster都是用的sticky session否则同步session信息对网络带
: 宽性能影响太大
|
|
|
z*******3
发帖数: 13709 | 11 这就是为啥我觉得vert.x比较好用的原因
嘿嘿
memcached
【在 g*****g 的大作中提到】
: 这是错的，大型应用通常尽量避免sticky session，因为会带来大量load balancing的
: 问题。你可以用cookie来存信息，或者使用distributed session store，如memcached
: 。这样可以保持应用stateless，在scalability上很重要。
|
h**********c
发帖数: 4120 | 12 看见活的gc，居然是个artist 兼职的tester
什么tect，２０年c++都不知道什么事儿
足3s,about 100g mem
我老本来打算好好测测，人当耳旁风，只好省了。
只可惜有几个老同事，人真心的不错
【在 z*******3 的大作中提到】
: 分布式n多个nodes
: 你不可能所有nodes同时stop the world吧？
: 另外tune一下jvm
: 尽量多触发小gc，而不是大gc，这样就可以控制gc时间
: 还有就是pool object也可以减少这些问题
: 一般内存中的gc中断不会比你网络上的latency要慢多少
: 客户端完全没有必要搭理，你ping一下都多少ms了
: 一般gc也就是ms级的，对于server来说
: 当然内存大的话，gc停顿也有可能变长
|
h**********c
发帖数: 4120 | 13 能抓到这个三秒的gc
也是因为我老在另外一个server上抓log
所以架构这种东西真心是钱烧出来的
还得烧对地方
否则20亿也就烧出个屁来 |
z*******3
发帖数: 13709 | 14 多大内存？
策略无脑改成g1试试
3s有些久了，尤其是如果是大内存的话
等3s黄花菜都凉了
一般分布式都是爆节点，而不是爆内存
光爆内存的话，大heap就会导致gc时间变长
所以要scale out而不是scale up
hpc那一套没戏，又难做又贵
【在 h**********c 的大作中提到】
: 能抓到这个三秒的gc
: 也是因为我老在另外一个server上抓log
: 所以架构这种东西真心是钱烧出来的
: 还得烧对地方
: 否则20亿也就烧出个屁来
|
z*******3
发帖数: 13709 | 15 100g如果不好好tune一下的话
是有些头疼，可以把前后端分离
前端上一些异步之类的，这样可以一定程度上优化响应速度
persistence如果你选择了cp系统
怎么tune也都还是会慢
建议上ap系统，然后就比较容易分布了
把每个节点的heap压小一点
这样gc停顿就小很多了，反正都分布了
上100g内存感觉很没有必要
一般我一个节点就是10g，20g，差不多
搭配g1，还没怎么遇到过gc导致的长停顿的问题
【在 h**********c 的大作中提到】
: 看见活的gc，居然是个artist 兼职的tester
: 什么tect，２０年c++都不知道什么事儿
: 足3s,about 100g mem
: 我老本来打算好好测测，人当耳旁风，只好省了。
: 只可惜有几个老同事，人真心的不错
|
z*******3
发帖数: 13709 | 16 还有server side的东西
尽量用上spring，这样你gc的次数自然就少了
至少logic部分，spring都帮你actively initiate起来
虽然启动小慢，但是每次执行就快了
gc也管不到这部分beans
从这点上说，spring等于帮你pool了一堆object
而且这些object感觉就是高级一点的util
就像fp里面functions的集合一样 |
g*****g
发帖数: 34805 | 17 JVM分配内存不是越大越好，这个就是原因之一。也是为啥云上起一堆结点性价比很高
的原因。你弄个牛逼机器，还是得虚拟化才能都用上。一般使用，我觉得 32g到头了。
【在 h**********c 的大作中提到】
: 看见活的gc，居然是个artist 兼职的tester
: 什么tect，２０年c++都不知道什么事儿
: 足3s,about 100g mem
: 我老本来打算好好测测，人当耳旁风，只好省了。
: 只可惜有几个老同事，人真心的不错
|
