为什么我们在同一台服务器上使用多应用服务器实例

Seb*_*ber 14 java jboss tomcat glassfish java-ee

我想有一个很好的理由,但我不明白为什么有时我们会在同一台物理服务器上放置5个具有相同web应用程序的实例.

它与多处理器架构的优化有关吗?JVM或其他什么允许的最大ram限制?

Fav*_*ius 17

嗯......经过很长一段时间我再次看到这个问题:)

好吧,一台机器上的多个JVM实例解决了很多问题.首先让我们面对这一点:尽管JDK 1.7正在出现,但很多遗留应用程序都是使用JDK 1.3或1.4或1.5开发的.而JDK的主要部分仍然存在.

现在问你的问题:

从历史上看,系统架构师通过在一个盒子上部署多个JVM来解决三个主要问题:

  1. Garbage collection inefficiencies:随着堆大小的增加,垃圾收集周期 - 特别是对于主要收集 - 由于采用单线程GC,因此往往会在处理过程中引入显着的延迟.多个JVM通过允许一般较小的堆大小并在GC循环期间启用一些并发度来解决这个问题(例如,有四个节点,当一个进入GC时,你仍然有三个其他主动处理).

  2. Resource utilization:较旧的JVM无法有效扩展到四个CPU左右.答案?为盒子中的每2个CPU运行一个单独的JVM(里程可能因应用程序而异,当然).

  3. 64-bit issues:较旧的JVM无法分配超出32位最大值的堆大小.同样,多个JVM允许您最大化资源利用率.

  4. 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

希望这会帮助你.


San*_*rma 6

我想你指的是应用程序集群.

AFAIK,JVM产生的堆大小非常大,但在垃圾收集方面存在问题,但我确信通过使用GC算法和参数可以将损坏降到最低.此外,群集应用程序没有单点故障.如果一个节点发生故障,其余节点可以继续为客户端提供服务.这是"基于消息的体系结构"非常适合可伸缩性的原因之一.每个请求都映射到一条消息,然后可以由集群中的任何节点拾取.

另一点是同时为多个请求提供服务,以防您的应用程序不幸地明智地使用synchronized关键字.我们目前有一个遗留应用程序,它有很多共享状态(不幸的是),因此并发请求处理是通过产生大约20个JVM进程和一个中央调度单元来完成的,该单元执行所有调度工作.;-)