Fav*_*ius 17
嗯......经过很长一段时间我再次看到这个问题:)
好吧,一台机器上的多个JVM实例解决了很多问题.首先让我们面对这一点:尽管JDK 1.7正在出现,但很多遗留应用程序都是使用JDK 1.3或1.4或1.5开发的.而JDK的主要部分仍然存在.
现在问你的问题:
从历史上看,系统架构师通过在一个盒子上部署多个JVM来解决三个主要问题:
Garbage collection inefficiencies:随着堆大小的增加,垃圾收集周期 - 特别是对于主要收集 - 由于采用单线程GC,因此往往会在处理过程中引入显着的延迟.多个JVM通过允许一般较小的堆大小并在GC循环期间启用一些并发度来解决这个问题(例如,有四个节点,当一个进入GC时,你仍然有三个其他主动处理).
Resource utilization:较旧的JVM无法有效扩展到四个CPU左右.答案?为盒子中的每2个CPU运行一个单独的JVM(里程可能因应用程序而异,当然).
64-bit issues:较旧的JVM无法分配超出32位最大值的堆大小.同样,多个JVM允许您最大化资源利用率.
Availability:人们有时在一个盒子上运行多个JVM的最后一个原因是可用性.虽然这种做法确实不能解决硬件故障,但它确实解决了应用服务器的单个实例中的故障.
取自(http://www.theserverside.com/discussions/thread.tss?thread_id=20044)
我大多看过weblogic.以下是进一步阅读的链接:
http://download.oracle.com/docs/cd/E13222_01/wls/docs92/perform/WLSTuning.html#wp1104298
希望这会帮助你.
我想你指的是应用程序集群.
AFAIK,JVM产生的堆大小非常大,但在垃圾收集方面存在问题,但我确信通过使用GC算法和参数可以将损坏降到最低.此外,群集应用程序没有单点故障.如果一个节点发生故障,其余节点可以继续为客户端提供服务.这是"基于消息的体系结构"非常适合可伸缩性的原因之一.每个请求都映射到一条消息,然后可以由集群中的任何节点拾取.
另一点是同时为多个请求提供服务,以防您的应用程序不幸地明智地使用synchronized关键字.我们目前有一个遗留应用程序,它有很多共享状态(不幸的是),因此并发请求处理是通过产生大约20个JVM进程和一个中央调度单元来完成的,该单元执行所有调度工作.;-)
| 归档时间: | 
 | 
| 查看次数: | 11472 次 | 
| 最近记录: |