有点web服务器不必安装jdk，因为自带了，如weblogic。
tomcat web容器，主要和有jsp和servlet有关， 没有tomcat 通过一定技术是可以运行jsp和serlet所以说JVM跑着tomcat，而没有JVM tomcat就废物了
答：这个具体取决于你的物理服务器的硬件配置，以及虚拟机的资源消耗情况来定。没有固定的算法。但是一般会有几个限制:
1.内存内存基本上是一个硬限制。物理服务器的内存肯定是有限的。例如，一台服务器有8core,8G内存，通常hypervisor会占用512M内存，大概还剩下7.5G内存，假设每个虚拟机的配置是1corecpu,1G内存，那么在此机器上最多可以运行7个这样的虚拟机。再创建新的虚拟机时，就会报错说内存不够。在此情况下，每个虚拟机在满负载情况下最多可以拥有1个cpucore的运算能力，1G的内存空间。
当然，现在的hypervisor基本上都支持over-commit的功能，也就是说，如果你的内存只有8G,但是设定一定比例的overcommit，例如50%，那么你可以最多分出去12G内存。还是上面那个例子，如果设定overcommit为50%，那么最多可以创建11个虚拟机(1core,1Gmem)。在服务器虚拟化方面，建议overcommit设置的不要太高，一般20%。在桌面虚拟化方面，可以将overcommit设置到50%.
2.网卡如果服务器只有一个网卡，所有虚拟机的网络流量都是通过一块网卡出去，虚拟机越多，每个虚拟机可以使用的带宽就会越少，这个是需要综合考虑。例如使用多个网卡等。
3.CPUCPU资源基本上都是采用时分复用，也就是时间片的方式来轮询的。
4.磁盘I/O是本地磁盘还是网络磁盘？如果是网络磁盘，是使用的iSCSI还是光纤？不同的情况，负载是不一样的。
一般一台服务器上能跑多少个虚拟机，需要综合考虑物理服务器，虚拟机负载等方面的整体情况，再来计算。没有一个固定的公式。
实践中我们发现对于大多数的应用领域，评估一个垃圾收集(GC)算法需要如下三个标准：
首先让我们来明确垃圾收集(GC)中的两个术语：
JVM在专门的线程(GC Threads)中执行GC，只要GC线程是活动的，它们将与应用程序线程(application threads)争用当前可用的CPU时钟周期。 简单点来说，吞吐量是指用户应用程序线程用时占程序总用时的比例。 例如，吞吐量99/100意味着100秒的程序执行时间中用户应用程序线程运行了99秒， 而在这段时间内GC线程只运行了1秒。
术语”暂停时间”是指一个时间段内应用程序线程让与GC线程执行而完全暂停。 例如，GC期间100毫秒的暂停时间意味着在这100毫秒期间内没有用户应用程序线程是活动的。 如果说一个正在运行的应用程序有100毫秒的“平均暂停时间”，那么就是说该用户应用程序所有的暂停时间平均长度为100毫秒。 同样，100毫秒的“最大暂停时间”是指该用户应用程序所有的暂停时间最大不超过100毫秒。
1.高吞吐量最好，因为这会让应用程序的最终用户感觉只有应用程序线程在做“生产性”工作。 直觉上，吞吐量越高程序运行越快。
2.低暂停时间最好，因为从最终用户的角度来看不管是GC还是其他原因导致一个应用被挂起始终是不好的。 这取决于应用程序的类型，有时候甚至短暂的200毫秒暂停都可能打断终端用户体验。 因此，具有低的最大暂停时间是非常重要的，特别是对于一个交互式应用程序。
3.不幸的是”高吞吐量”和”低暂停时间”是一对相互竞争的目标（矛盾）。
这样想想看，为了清晰起见简化一下：GC需要一定的前提条件以便安全地运行。 例如，必须保证应用程序线程在GC线程试图确定哪些对象仍然被引用和哪些没有被引用的时候不修改对象的状态。 为此，应用程序在GC期间必须停止(或者仅在GC的特定阶段，这取决于所使用的算法)。 然而这会增加额外的线程调度开销：直接开销是上下文切换，间接开销是因为缓存的影响。 加上JVM内部安全措施的开销，这意味着GC及随之而来的不可忽略的开销，将增加GC线程执行实际工作的时间。 因此我们可以通过尽可能少运行GC来最大化吞吐量，例如，只有在不可避免的时候进行GC，来节省所有与它相关的开销。
然而，仅仅偶尔运行GC意味着每当GC运行时将有许多工作要做，因为在此期间积累在堆中的对象数量很高。 单个GC需要花更多时间来完成， 从而导致更高的平均和最大暂停时间。 因此，考虑到低暂停时间，最好频繁地运行GC以便更快速地完成。 这反过来又增加了开销并导致吞吐量下降，我们又回到了起点。
综上所述，在设计（或使用）GC算法时，我们必须确定我们的目标：一个GC算法只可能针对两个目标之一（即只专注于最大吞吐量或最小暂停时间），或尝试找到一个二者的折衷。
Throughput收集器有两个基本操作：一是回收新生代垃圾（Minor GC）；二是回收老年代垃圾(Full GC)。
下图是新生代回收之前和之后的情况
Minor GC通常在新生代空间用尽时。新生代收集器会把Eden空间中的所有对象挪走：一部分被移到Survivor中，其它被移到老年代。
下图是Full gc之前之后的对比图
老年代垃圾收集会收集新生代中所有的对象（包括Survivor中的对象），只有那些有活跃引用的对象，或者已经经过压缩整理的对象会继续在老年代中留存下来。其余对象将被回收。
Throughput收集器的调优几乎都是围绕停顿时间进行的，寻求堆的总体大小、新生代的大小以及老年代大小之间的平衡 。
两种取舍：
1、经典技术上的取舍，时间和空间上的取舍；
2、第二个取舍与完成垃圾回收所需的时长有关，增大堆能够减少Full GC停顿发送的频率****， 但也有局限性：由于GC时间变得更长，平均响应时间也会变长（老年代空间很大，在回收老年代耗时很长）。类似的，为新生代分配更多的堆空间可以缩短Full GC的停顿时间，不过这又增大老年代垃圾回收的频率（因为老年代空间保持不变或者变得更小了）。
看一个示例说明堆大小与吞吐量的关系，在该示例中是关闭了JVM自适应调整堆大小的情况
在Throughput收集器中，可自适应调整会重新分配堆（以及代）的大小。使用这些标志可以设置相应的性能指标：-XX:MaxGCPauseMillis=N和-XX:GCTimeRatio=N。
-XX:MaxGCPauseMillis ：标志用于设定应用可承受的最大停顿时间。可以设置为0或者一些非常小的值，譬如50毫秒。请注意，这个标志设定的值同时影响Minor GC和Full GC。如果设置的值非常小，那么应用的老年代最终就会非常小，导致频繁的Full GC（例如，希望程序在50毫秒内完成垃圾回收，这将会触发非常频繁的Full GC，对应用程序的性能而言将是灾难性的。）。因此，设定该值时，尽量保持理性，将该值设定为可达到的合理值。缺省情况下， 不设置该参数。
-XX:GCTimeRatio： 标志可以设置你希望应用程序在垃圾回收上花费多少时间（与应用线程的运行时间相比较）。它是一个百分比，默认值是99。
N值得计算稍微有些复杂。将N值代入下面的公式可以计算理想情况下应用线程的运行时间所占的百分比：
将GCTimeRatio的默认值99代入公式得到0.99，这意味着应用程序的运行时间占总时间的99%，只有1%的时间消耗在垃圾回收上。
再例如GCTimeRatio=95时，并不是意味使用总时间5%去做垃圾回收；它表示的是最多会使用总时间的1.94%去做垃圾回收。所以，如果你期望程序工作时间在95%，则需要变换一下公式计算 GCTimeRatio 是一个更容易操作的方法。
对于95%（0.95）的吞吐量目标，利用该公式计算出的 GCTimeRatio 是19 。
JVM使用这两个标志在堆的初始值（-Xms，-XmX）之间的堆的大小。 MaxGCPauseMillis的优先级别最高： 如果设置了这个值，新生代和老年代会随之进行调整，直到满足对应停顿时间的目标。一旦这个目标达成，堆的总容量就开始逐渐增大，直到运行时间的比率达到设定值。这两个目标都达成后，开始缩减堆大小，尽可能的以最小堆大小来满足这两个目标。
该系列的第五部分我们已经讨论过年轻代的垃圾收集器。 对于年老代，HotSpot虚拟机提供两类垃圾收集算法(除了新的G1垃圾收集算法)，第一类算法试图最大限度地提高吞吐量，而第二类算法试图最小化暂停时间。 今天我们的重点是第一类，”面向吞吐量”的垃圾收集算法。
我们希望把重点放在JVM配置参数上，所以我只会简要概述HotSpot提供的面向吞吐量(throughput-oriented)垃圾收集算法。 当年老代中由于缺乏空间导致对象分配失败时会触发垃圾收集器(事实上，”分配”的通常是指从年轻代提升到年老代的对象)。 从所谓的”GC根”(GC roots)开始，搜索堆中的可达对象并将其标记为活着的，之后，垃圾收集器将活着的对象移到年老代的一块无碎片(non-fragmented)内存块中，并标记剩余的内存空间是空闲的。 也就是说，我们不像复制策略那样移到一个不同的堆区域，像年轻代垃圾收集算法所做的那样。 相反地，我们把所有的对象放在一个堆区域中，从而对该堆区域进行碎片整理。 垃圾收集器使用一个或多个线程来执行垃圾收集。 当使用多个线程时，算法的不同步骤被分解，使得每个收集线程大多时候工作在自己的区域而不干扰其他线程。 在垃圾收集期间，所有的应用程序线程暂停，只有垃圾收集完成之后才会重新开始。 现在让我们来看看跟面向吞吐量垃圾收集算法有关的重要JVM配置参数。
我们使用该标志来激活串行垃圾收集器，例如单线程面向吞吐量垃圾收集器。 无论年轻代还是年老代都将只有一个线程执行垃圾收集。 该标志被推荐用于只有单个可用处理器核心的JVM。 在这种情况下，使用多个垃圾收集线程甚至会适得其反，因为这些线程将争用CPU资源，造成同步开销，却从未真正并行运行。
有了这个标志，我们告诉JVM使用多线程并行执行年轻代垃圾收集。 在我看来，Java 6中不应该使用该标志因为-XX:+UseParallelOldGC显然更合适。 需要注意的是Java 7中该情况改变了一点(详见本概述)，就是-XX:+UseParallelGC能达到-XX:+UseParallelOldGC一样的效果。
该标志的命名有点不巧，因为”老”听起来像”过时”。 然而，”老”实际上是指年老代，这也解释了为什么-XX:+UseParallelOldGC要优于-XX:+UseParallelGC：除了激活年轻代并行垃圾收集，也激活了年老代并行垃圾收集。 当期望高吞吐量，并且JVM有两个或更多可用处理器核心时，我建议使用该标志。
作为旁注，HotSpot的并行面向吞吐量垃圾收集算法通常称为”吞吐量收集器”，因为它们旨在通过并行执行来提高吞吐量。
通过-XX:ParallelGCThreads=<value>我们可以指定并行垃圾收集的线程数量。 例如，-XX:ParallelGCThreads=6表示每次并行垃圾收集将有6个线程执行。 如果不明确设置该标志，虚拟机将使用基于可用(虚拟)处理器数量计算的默认值。 决定因素是由Java Runtime。availableProcessors()方法的返回值N，如果N<=8，并行垃圾收集器将使用N个垃圾收集线程，如果N>8个可用处理器，垃圾收集线程数量应为3+5N/8。
当JVM独占地使用系统和处理器时使用默认设置更有意义。 但是，如果有多个JVM(或其他耗CPU的系统)在同一台机器上运行，我们应该使用-XX:ParallelGCThreads来减少垃圾收集线程数到一个适当的值。 例如，如果4个以服务器方式运行的JVM同时跑在在一个具有16核处理器的机器上，设置-XX:ParallelGCThreads=4是明智的，它能使不同JVM的垃圾收集器不会相互干扰。
吞吐量垃圾收集器提供了一个有趣的(但常见，至少在现代JVM上)机制以提高垃圾收集配置的用户友好性。 这种机制被看做是HotSpot在Java 5中引入的”人体工程学”概念的一部分。 通过人体工程学，垃圾收集器能将堆大小动态变动像GC设置一样应用到不同的堆区域，只要有证据表明这些变动将能提高GC性能。 “提高GC性能”的确切含义可以由用户通过-XX:GCTimeRatio和-XX:MaxGCPauseMillis(见下文)标记来指定。
重要的是要知道人体工程学是默认激活的。 这很好，因为自适应行为是JVM最大优势之一。 不过，有时我们需要非常清楚对于特定应用什么样的设置是最合适的，在这些情况下，我们可能不希望JVM混乱我们的设置。 每当我们发现处于这种情况时，我们可以考虑通过-XX:-UseAdaptiveSizePolicy停用一些人体工程学。
通过-XX:GCTimeRatio=<value>我们告诉JVM吞吐量要达到的目标值。 更准确地说，-XX:GCTimeRatio=N指定目标应用程序线程的执行时间(与总的程序执行时间)达到N/(N+1)的目标比值。 例如，通过-XX:GCTimeRatio=9我们要求应用程序线程在整个执行时间中至少9/10是活动的(因此，GC线程占用其余1/10)。 基于运行时的测量，JVM将会尝试修改堆和GC设置以期达到目标吞吐量。 -XX:GCTimeRatio的默认值是99，也就是说，应用程序线程应该运行至少99%的总执行时间。
通过-XX:GCTimeRatio=<value>告诉JVM最大暂停时间的目标值(以毫秒为单位)。 在运行时，吞吐量收集器计算在暂停期间观察到的统计数据(加权平均和标准偏差)。 如果统计表明正在经历的暂停其时间存在超过目标值的风险时，JVM会修改堆和GC设置以降低它们。 需要注意的是，年轻代和年老代垃圾收集的统计数据是分开计算的，还要注意，默认情况下，最大暂停时间没有被设置。
如果最大暂停时间和最小吞吐量同时设置了目标值，实现最大暂停时间目标具有更高的优先级。 当然，无法保证JVM将一定能达到任一目标，即使它会努力去做。 最后，一切都取决于手头应用程序的行为。
当设置最大暂停时间目标时，我们应注意不要选择太小的值。 正如我们现在所知道的，为了保持低暂停时间，JVM需要增加GC次数，那样可能会严重影响可达到的吞吐量。 这就是为什么对于要求低暂停时间作为主要目标的应用程序(大多数是Web应用程序)，我会建议不要使用吞吐量收集器，而是选择CMS收集器。 CMS收集器是本系列下一部分的主题。
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）