m*m
发帖数: 47 | 1 java的gc 就是整个java-based 系统的瓶颈。当成千上万的请求进来时， jvm说我要gc
了， 那整个系统就直接暂停了。java的gc是不可能完全disable的。
真还得c/c++一类的， 甚至直接上 ASIC. |
z****g
发帖数: 75 | 2 Java虽然有些问题，12306还是架构问题，语言没啥关系
用Java也许比用C++得多2～3倍的机子，但是不至于不能做
gc
【在 m*m 的大作中提到】
: java的gc 就是整个java-based 系统的瓶颈。当成千上万的请求进来时， jvm说我要gc
: 了， 那整个系统就直接暂停了。java的gc是不可能完全disable的。
: 真还得c/c++一类的， 甚至直接上 ASIC.
|
w**z
发帖数: 8232 | 3 如果架构能做到horizontal scalable, 一个JVM gc 影响有限。关键还是架构。
gc
【在 m*m 的大作中提到】
: java的gc 就是整个java-based 系统的瓶颈。当成千上万的请求进来时， jvm说我要gc
: 了， 那整个系统就直接暂停了。java的gc是不可能完全disable的。
: 真还得c/c++一类的， 甚至直接上 ASIC.
|
s*****r
发帖数: 43070 | 4 现在内存这么大，gc都是时刻在做，已经没有暂停的需要
gc
【在 m*m 的大作中提到】
: java的gc 就是整个java-based 系统的瓶颈。当成千上万的请求进来时， jvm说我要gc
: 了， 那整个系统就直接暂停了。java的gc是不可能完全disable的。
: 真还得c/c++一类的， 甚至直接上 ASIC.
|
n****1
发帖数: 1136 | 5 在memory wall越来越严重的时代, stack/heap allocation的差距已经越来越小了. 再
加上分布式运算, heap+GC的损耗可以忽略不计. |
g*****g
发帖数: 34805 | 6 这年头G1都存在这么久了，除非是实时系统，还纠结GC的只能说明没写过。 |
l**********n
发帖数: 8443 | |
w**z
发帖数: 8232 | 8 其实内存越大，GC 的stop the world pause 才越要注意 但现在都是几百个机器部署
，单机gc 可以忽略不计。
【在 s*****r 的大作中提到】
: 现在内存这么大，gc都是时刻在做，已经没有暂停的需要
:
: gc
|
m*m
发帖数: 47 | 9 其实java gc的问题在于不确定性。你不可能知道它什么时候开始， 什么时候结束。不
确定性在设计大系统上是很忌讳的。
比方说， 有几百台机器同时运行java 程序（ hadoop, cassandra, jetty, 等等），
存在一种可能就是这几百个jvm在某一时间同时进行gc. 当这种情况发生后, 会连带一
堆反应，进而导致服务中断。 如果这几百个机器是线下系统， 做batch
processing, 那没人会留意这几秒或几十秒。但如果是线上系统， 那用户越多， 中
断越严重。
java系统对12306一类的网站来说，是先天不足的。 |
l*****9
发帖数: 9501 | |
|
|
g*****g
发帖数: 34805 | 11 GC跟stop the world GC是两码事。现在的GC算法，stop the world的时间本来就很短
。除非机器不够被flooded, 或者有bug, 不可能出现同时stop world GC这种事情。这
世界上最大规模的一些应用都跑着JVM后端，包括amazon, ebay, taobao。没听说他们
有这个问题。
【在 m*m 的大作中提到】
: 其实java gc的问题在于不确定性。你不可能知道它什么时候开始， 什么时候结束。不
: 确定性在设计大系统上是很忌讳的。
: 比方说， 有几百台机器同时运行java 程序（ hadoop, cassandra, jetty, 等等），
: 存在一种可能就是这几百个jvm在某一时间同时进行gc. 当这种情况发生后, 会连带一
: 堆反应，进而导致服务中断。 如果这几百个机器是线下系统， 做batch
: processing, 那没人会留意这几秒或几十秒。但如果是线上系统， 那用户越多， 中
: 断越严重。
: java系统对12306一类的网站来说，是先天不足的。
|
m*m
发帖数: 47 | 12 嗯， 不过如果你仔细读了 CMS 和G1, 你会发现在这些GC都没说他们能够完全消除
pause time, 只是最大限度减少而已。
对于enterprise application 来说， 内存够大， 用户群够小， G1/CMS已经够好了,
用户们完全可能觉擦不到gc在运行。
但当面对12306的用户群时，巨大的访问量会给jvm带来很大的压力，我估计memory
fragmentation 会迫使jvm放弃G1/CMS, 转而运行STW GC来回收heap. 恶性循环就
此开始。
那些jvm运用(amazon, ebay, taobao)没有太多的背景信息，不好评价。 如果是线下程
序（batching processing, map reduce 等等)， 那完全可能， 因为gc对他们的影响
很小， 没人会在意。
【在 g*****g 的大作中提到】
: GC跟stop the world GC是两码事。现在的GC算法，stop the world的时间本来就很短
: 。除非机器不够被flooded, 或者有bug, 不可能出现同时stop world GC这种事情。这
: 世界上最大规模的一些应用都跑着JVM后端，包括amazon, ebay, taobao。没听说他们
: 有这个问题。
|
z****e
发帖数: 54598 | 13 有一种东西叫做real time jvm
不过没多少市场
12306不是web的问题
主要是运力问题
运力问题不解决
你用天顶星科技都没用 |
g*****g
发帖数: 34805 | 14 淘宝光棍节都能顶过去，你操心过头了。
了,
【在 m*m 的大作中提到】
: 嗯， 不过如果你仔细读了 CMS 和G1, 你会发现在这些GC都没说他们能够完全消除
: pause time, 只是最大限度减少而已。
: 对于enterprise application 来说， 内存够大， 用户群够小， G1/CMS已经够好了,
: 用户们完全可能觉擦不到gc在运行。
: 但当面对12306的用户群时，巨大的访问量会给jvm带来很大的压力，我估计memory
: fragmentation 会迫使jvm放弃G1/CMS, 转而运行STW GC来回收heap. 恶性循环就
: 此开始。
: 那些jvm运用(amazon, ebay, taobao)没有太多的背景信息，不好评价。 如果是线下程
: 序（batching processing, map reduce 等等)， 那完全可能， 因为gc对他们的影响
: 很小， 没人会在意。
|
s****u
发帖数: 1433 | 15 错。不是运力问题，是思路问题。
假设只有一张票，运力问题无限大，但是定票问题就是菜。
随机给某个吊丝，或者直接发给习胖就解决了。
那么现在票多了，运力问题相对小了，为什么订票反而出问题了呢。
那就是思路死丢皮德。
【在 z****e 的大作中提到】
: 有一种东西叫做real time jvm
: 不过没多少市场
: 12306不是web的问题
: 主要是运力问题
: 运力问题不解决
: 你用天顶星科技都没用
|
w**z
发帖数: 8232 | 16 CMS 也是有stop the world pause， 只不过它很短， 发生在initial mark 和remark
phase。 JVM 的一个误区，是觉得内存越大越好，其实内存越大，GC pause 越长。
Cassandra 就不建议每个JVM heap 超过8G.CMS 在heap 超过8G，会有问题。C＊尽量使
用off heap memory， OS cache etc. Kafka 也是相同的思路，尽量利用现成的 linux
pagecache.
其实对distributed system 来说，单机性能，并不重要，主要是做到horizontal
scalable.单机都是commodity hardware， 不行，就加机器。在这上，Netflix 做的就
非常好，那不是那么简单的。数以百记的service， calling each other， 数以万记
的machine， 不停的deployment， machine up and down, joining and leaving
pool.
你所说的 “ 但当面对12306的用户群时，巨大的访问量会给jvm带来很大的压力，我估
计memory
了, |
m*m
发帖数: 47 | 17 嗯， 同意你的大部分看法， 但对加机器来解决问题就有分歧了。如果是为了planed&#
160;scale out 而加， 那只是把gc的问题埋的更深， 如果条件合适， 仍然会trigger
. 如果是临时加， 那直接说明系统本身有问题， 是在救火而已。
gc对于商业程序来说，是利大于弊。但对12306我感觉是弊大于利了。
remark
linux
【在 w**z 的大作中提到】
: CMS 也是有stop the world pause， 只不过它很短， 发生在initial mark 和remark
: phase。 JVM 的一个误区，是觉得内存越大越好，其实内存越大，GC pause 越长。
: Cassandra 就不建议每个JVM heap 超过8G.CMS 在heap 超过8G，会有问题。C＊尽量使
: 用off heap memory， OS cache etc. Kafka 也是相同的思路，尽量利用现成的 linux
: pagecache.
: 其实对distributed system 来说，单机性能，并不重要，主要是做到horizontal
: scalable.单机都是commodity hardware， 不行，就加机器。在这上，Netflix 做的就
: 非常好，那不是那么简单的。数以百记的service， calling each other， 数以万记
: 的machine， 不停的deployment， machine up and down, joining and leaving
: pool.
|
q*c
发帖数: 9453 | 18 你知道吧，如果条件合适，面前所有空气分子随机运动随机了同一个方向。。。你的短
小人生就悲剧了，哈哈哈。
你会不会害怕的无法睡觉啊？哈哈哈。
&#
trigger
【在 m*m 的大作中提到】
: 嗯， 同意你的大部分看法， 但对加机器来解决问题就有分歧了。如果是为了planed&#
: 160;scale out 而加， 那只是把gc的问题埋的更深， 如果条件合适， 仍然会trigger
: . 如果是临时加， 那直接说明系统本身有问题， 是在救火而已。
: gc对于商业程序来说，是利大于弊。但对12306我感觉是弊大于利了。
:
: remark
: linux
|
