在负载下，jvm更快吗? [英] is the jvm faster under load?

问题描述

大量的个人经验，轶事证据和一些初步的分析表明，当Java服务器(通常运行Oracle 1.6 JVM)在负载相当大的情况下(显然只是达到一定程度)时，其响应时间更快.

Lots of personal experience, anecdotal evidence, and some rudimentary analysis suggests that a Java server (running, typically, Oracle's 1.6 JVM) has faster response times when it's under a decent amount of load (only up to a point, obviously).

我认为这并不是纯粹的热点，因为当流量减少时，响应时间会再次放慢.

I don't think this is purely hotspot, since response times slow down a bit again when the traffic dies down.

在许多情况下，我们可以通过平均服务器日志的响应时间来证明这一点……在某些情况下，平均速度提高了20％，并且标准偏差较小.

In a number of cases we can demonstrate this by averaging response times from server logs ... in some cases it's as high as 20% faster, on average, and with a smaller standard deviation.

任何人都可以解释为什么会这样吗?这可能是真正的效果，还是平均值只是误导了?我已经通过数项工作已经看到了很多年了，并且倾向于将其陈述为事实，但是对于原因却没有任何解释.

Can anyone explain why this is so? Is it likely a genuine effect, or are the averages simply misleading? I've seen this for years now, through several jobs, and tend to state it as a fact, but have no explanation for why.

谢谢， 埃里克

推荐答案

编辑相当大的修改，用于措辞并在整个过程中添加了更多细节.

EDIT a fairly large edit for wording and adding more detail throughout.

一些想法:

1. 当执行一段代码比执行其他代码多得多(这是程序的热点)时，热点就会启动.从那一点开始，这段代码(对于正常路径)明显更快.热点编译后的调用率并不重要，因此我认为这不会引起您提到的影响.

1. Hotspot kicks in when a piece of code is being executed significantly more than other pieces (it's the hot spot of the program). This makes that piece of code significantly faster (for the normal path) from that point forward. The rate of call after the hotspot compilation is not important, so I don't think this is causing the effect you are mentioning.

效果真的吗?用统计数字欺骗自己很容易.并不是说您是，但是请确保结果中包含您的所有跑步记录，并且所有其他影响(例如其他程序，活动，和您的监视程序)都包含在结果中在所有情况下都是相同的.我有一个以上的监控程序，例如top， 行为差异).在某些情况下，当数据库上的缓存预热时，应用程序的性能会明显提高-相同数据库实例上其他应用程序的内存压力很大.

Is the effect real? It's very easy to trick yourself with statistics. Not saying you are, but be sure that all your runs are included in the result, and that all other effects (such as other programs, activity, and your monitoring program are the same in all cases. I have more than one had my monitoring program, such as top, cause a difference in behaviour). On one occasion, the performance of the application went up appreciably when the caches warmed up on the database - there was memory pressure from other applications on the same DB instance.

很可能涉及操作系统和/或CPU.在主程序从主要运行变为主要等待I/O时，操作系统和CPU都会主动和被动地执行一些操作来改善主程序的响应能力，反之亦然，包括:

The Operating System and/or CPU may well be involved. The OS and CPU both actively and passively do things to improve the responsiveness of the main program as it moves from being mainly running to being mainly waiting for I/O and vice versa, including:

1. 在不使用时将OS分页内存分配到磁盘，而在程序运行时将其分页回RAM
2. 操作系统将缓存常用的磁盘块，这可能再次提高应用程序性能
3. CPU指令和内存缓存中填充了活动程序的指令和数据

对内存分页效果特别敏感的Java应用程序，因为:

Java applications particularly sensitive to memory paging effects because:

1. 典型的Java应用程序服务器会将几乎所有可用内存预分配给Java.大内存使应用程序本质上对内存效果更加敏感
2. 用于管理Java内存的分代垃圾收集器最终会在许多页面上创建新对象，因此，与其他语言相比，对应用程序的每个请求将需要更多的页面请求. (这主要是针对尚未通过许多垃圾回收的新"对象.提升为永久代的对象实际上是非常紧凑地存储的)
3. 由于大多数可用的物理内存是在系统上分配的，因此内存总是有压力，并且最大，最近最少运行的应用程序很适合分页.

考虑到这些因素，与内存需求较小的环境相比，存在页面遗失和性能下降的可能性要大得多.这些将在Java闲置一段时间后尤其明显.

With these considerations, there is much more probability that there will be page misses and therefore a performance hit than environments with smaller memory requirements. These will be particularly manifest after Java has been idle for some time.

如果使用Solaris或Mac，出色的 dTrace 可以跟踪特定于内存和磁盘的分页一个应用程序. JVM有许多dTrace挂钩，可用作启动和停止页面监视的触发器.

If you use Solaris or Mac, the excellent dTrace can trace memory and disk paging specific to an application. The JVM has numerous dTrace hooks that can be used as triggers to start and stop page monitoring.

在Solaris上，您可以使用大内存页(甚至超过1GB的大小)并将它们固定到RAM，这样就永远不会将它们分页出来.这样可以消除上述内存页问题.记住要为磁盘缓存和其他系统/维护/备份/管理应用程序留出大量可用内存.我确信其他操作系统也支持类似的功能.

On Solaris, you can use large memory pages (even over 1GB in size) and pin them to RAM so they will never be paged out. This should eliminate the memory page problem stated above. Remember to leave a good chunk of free memory for disk caching and for other system/maintenance/backup/management apps. I am sure that other OSes support similar features.

TL/DR::随着操作系统将程序和数据页从磁盘上移回，将常用磁盘页放入操作系统中，现代操作系统中当前正在运行的程序在几秒钟后似乎运行得更快.对于主程序，磁盘高速缓存以及OS指令和数据高速缓存将趋于变暖".这种影响并非JVM独有，但由于典型Java应用程序的内存需求和垃圾回收内存模型而更加明显.

TL/DR: The currently running program in modern operating systems will appear to run faster after a few seconds as the OS brings the program and data pages back from disk, places frequently used disk pages in disk cache and the OS instruction and data caches will tend to be "warmer" for the main program. This effect is not unique to the JVM but is more visible due to the memory requirements of typical Java applications and the garbage collection memory model.

这篇关于在负载下，jvm更快吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！