码迷,mamicode.com
首页 > 编程语言 > 详细

程序员诺禾:诺禾分析多任务中的java性能问题

时间:2020-05-31 20:01:10      阅读:81      评论:0      收藏:0      [点我收藏+]

标签:作用   原因   地址转换   img   指标   java   java性能   系统   can   

在生产实践中,为了降低公司运营成本,更好地利用系统容量,并提高资源使用率,我们经常会让多个应用程序,同时运行在同一台服务器上。

但是,万事有利就有弊。这几个共存的应用程序,有可能会互相影响;有时还会导致严重的性能问题。我就遇到过,几个程序同时运行,最后导致吞吐量急剧下降的情况。

所以,今天我们就来探讨,当多个 Java 应用程序共存在一个 Linux 系统上的时候,会产生哪些性能问题?我们又该怎么解决这些问题?

怎样理解多程序互相干扰?

为了更好地理解后面的性能问题,你需要先了解一下应用程序内存管理机制的背景知识。我们运行的是 Java 程序,所以先快速复习一下 Java 的 JVM 内存管理机制。

Java 程序在 Java 虚拟机 JVM 中运行,JVM 使用的内存区域称为堆。JVM 堆用于支持动态 Java 对象的分配,并且分为几个区域,称为“代”(例如新生代和老年代)。Java 对象首先在新生代中分配;当这些对象不再被需要时,它们会被称为 GC(GarbageCollection)的垃圾回收机制收集。发生 GC 时,JVM 会从根对象开始,一个个地检查所有对象的引用计数。如果对象的引用计数降为零,那就删除这个对象,并回收使用这个对象相应的存储空间。

GC 运行的某些阶段,会导致应用程序停止响应其他请求,这种行为,通常称为STW(Stop The Word 暂停)。 JVM 调优的重要目标之一,就是最大程度地减少 GC 暂停的持续时间。

复习完 JVM 内存管理机制,我们还要看一下与它相关的 Linux 的内存管理机制。

在 Linux 操作系统上,虚拟内存空间基本上是固定大小(例如 4KB)的页面。Linux 近年来有很多内存管理的优化,来提高内存使用效率和运行进程的性能。

Linux 内存管理有一个页面回收的机制。它在内部维护一个空闲页面(Free Page)列表,来满足未来应用程序的内存请求。当空闲页面的数量下降到一定水平时,操作系统就开始回收页面,并将新回收的页面添加到空闲列表中。

执行页面回收时,操作系统需要进行页面扫描(Page Scanning),以检查已经分配页面的活动性。Linux 有两个策略来进行页面扫描:后台扫描(由 kswapd 守护程序执行)和前台扫描(由进程自己执行)。

通常情况下,后台扫描就够了,应用程序的性能一般不会受到影响。但是当操作系统的内存使用非常大,空闲页面严重不足时,Linux 就会启动前台页面回收,也被称为直接回收或同步回收。在前台页面回收过程中,应用程序会停止运行,因此对应用程序影响很大。

Linux 还有一个页面交换(Page Swapping)的机制。是当可用内存不足时,Linux 会将某些内存页面换出到外部存储,以回收内存空间来运行新进程。当对应于换出页面的内存空间,再次处于活动状态时,系统会把这些页面重新从外部存储换入内存。

内存管理方面,THP(Transparent Huge Pages,透明大页面)是另外一个机制,也是为了提高进程的性能。我们在第 22 讲讨论过,如果系统用较大的页面,比如 2MB,而不是传统的 4KB,那么会带来一些好处,尤其是所需的地址转换条目数会减少。

尽管使用大页面的好处很早就为人所理解,但在 THP 引入之前,程序想使用大型页面并不容易。例如,操作系统启动时,需要保留大页面,并且进程必须显式调用才能分配大页面。而 THP 就是为了避免这两个问题而设计的,因此操作系统默认情况下就启用 THP。

了解了背景知识,你再看多个应用程序共存时的两个场景就不会有障碍了。第一个场景是应用程序启动时,第二个场景是应用程序稳定运行时。

应用程序启动时为什么会被其他程序干扰?

我们先看应用程序启动时的场景。当几个共存的应用程序共享有限的计算资源(包括内存和cpu)时,它们之间会相互影响。如果各自独立地运行,导致对系统计算资源的消耗无法协调一致,那么某些应用程序会出现问题。

我们要做个实验来暴露这些性能问题,看看这个问题的表象是什么,然后一起分析产生问题的原因。

这个实验采用了两个相同的 Java 程序。我们首先启动第一个程序,来占用一些内存,系统剩下约 20GB 的未使用内存。然后我们开始启动另外一个 Java 程序,这个程序需要 20GB的堆。

技术图片

 

在图中你可以看到,启动第二个程序之后,它的吞吐量是 12K/ 秒,持续时间约 30 秒。然后,吞吐量开始急剧下降。最坏的情况,在大约 20 秒的时间内,吞吐量几乎为零。有趣的是,过了一会儿,吞吐量又再次回到了稳定状态:12KB/ 秒。

下图显示了同一时间段的 GC 暂停信息。

技术图片

 

最初的 GC 暂停很低,都低于 50 毫秒;然后暂停就跳到数百毫秒之大。你甚至可以看到两次大于 1 秒的超大的暂停!大约 1 分钟后,GC 暂停再次下降至低于 50 毫秒,并变得稳定。

我们看到在启动期间,Java 程序的性能很差。因为问题是在启动 JVM 时发生的,我们有理由怀疑这与 JVM 的启动方式有关。我们检查了程序的的内存驻留大小(RES,ResidentSize),也就是进程使用的未交换的物理内存,图示如下。

技术图片

 

从图中你可以看到,尽管我们在启动 JVM 时,用参数将 JVM 的堆大小指定为 20GB(-Xmx20g 和 -Xms20g),但是 JVM 并不会从内存中一次全部拿到 20GB 的堆空间。相反,操作系统会在 JVM 的运行过程中不断地分配。也就是说,随着 JVM 实例化越来越多的对象,JVM 会从操作系统逐渐拿到更多的内存页面来容纳它们。

在分配过程中,操作系统将不断地检查空闲页面列表。如果发现可用内存量低于一定水平,操作系统就会开始回收页面,这个过程会花费 CPU 的时间。根据可用内存短缺的严重程度,回收过程可能会严重阻塞应用程序。在下图中,我们看到,可用内存明显地下降到了非常低的水平。

技术图片

 

下面这张图显示了 CPU 的空闲百分比(CPU 空闲百分比和繁忙百分比的和是 100%)。对比时间线,我们可以清楚地看到,页面回收过程会导致 CPU 开销,也就是空闲百分比下降了。

技术图片

 

那么怎么进行内存回收呢?

在 Linux 上,当可用内存不足时,操作系统会唤醒 kswapd 守护程序,开始在后台回收空闲页面。如果内存压力很大,操作系统就会被迫采取另外一种措施,就是直接地同步释放内存的前台。具体来讲,当可用空闲页面降到一个阈值之下,就会触发这种直接前台回收。

当发生直接前台回收时,Linux 会冻结正在申请内存的执行代码的应用程序,从而间接地导致大量的 GC 暂停。

此外,直接回收通常会扫描大量内存页面,以释放未使用的页面。那么我们就来看看 Linux直接回收内存页面的繁忙程度。下图就画出了 Linux 通过直接回收路径扫描的页面数。

技术图片

 

我们看到,在峰值时,通过直接回收,每秒扫描约 48K 个页面(即 200 MB);这个回收工作量是很大的,CPU 会不堪重负。

运行中的应用程序为什么会被别的程序干扰?

了解过程序启动时互相干扰的场景,我们再来考虑第二个场景:应用程序在持续运行中。

我们的实验是这样进行的。第一个 Java 程序以 20GB 的堆启动,并进入稳定状态。然后另外一个程序启动,并开始分配 50GB 的内存。

下图中体现了第一个程序的吞吐量。

技术图片

 

从图中我们看到,第一个程序从一开始就实现了稳定的 12K/ 秒的吞吐量。然后,吞吐量急剧下降到零,这个零吞吐量的过程持续了约 2 分钟。从那时起,吞吐量一直在发生相当大的变化:有时吞吐量是 12K/ 秒,其他时候又降为零。

我们也观察了 JVM 的暂停,用下图所示。

技术图片

 

从图中我们看到,在稳定状态下,GC 暂停几乎为零,然后居然有一个超级大的暂停;多大呢?55 秒!从那时起,GC 暂停持续变化,但很少恢复为零。大多数暂停时间为几秒钟。

我们观察到,其他应用程序的运行会严重影响本程序的性能。各种观察的结论是,系统处于内存压力之下,操作系统内存会有很多和外部存储的页面交换活动。在下图中,我们看到操作系统交换出了很多内存页面到外部存储空间。

技术图片

 

这些换出的内存页面很多属于 Java 程序(也就是堆空间)。如果 JVM 需要进行堆上的垃圾回收,也就是 GC,那么 GC 需要扫描 JVM 对象,以收集失效的对象。如果扫描的对象恰好是分配在换出的页面上,那么 JVM 需要先将它们从外部存储交换空间重新载入到内存中。从外部存储载入内存需要一些时间,因为交换空间通常位于磁盘驱动器上。

所有这些时间,都会算在 GC 暂停之中。因此,程序会看到较大的 GC 暂停。下图就显示了大量的从外部存储载入页面的活动。

技术图片

 

尽管页面交换活动会增加 GC 暂停时间,似乎可以解释刚刚看到的 JVM 暂停。但是,我怀疑,仅是这个原因根本无法解释生产中看到的很大暂停,比如超过 55 秒的暂停。你可能会问,我为什么有这样的怀疑?因为我在许多 GC 暂停的过程中,观察到了较高的系统 CPU使用。

比如在下图中,我们观察到,系统也处于严重的 CPU 压力下。

技术图片

 

CPU 的高使用率不能完全归因于页面交换活动,因为页面交换通常不会占用大量 CPU。所以,其中“必有隐情”:一定是有其他活动在大量使用 CPU。我们通过检查了各种系统性

能指标,最终确定了根因:是由于 THP 的机制,该机制严重加剧了程序性能和系统性能的下降。

具体来说,Linux 启用 THP 后,当应用程序分配内存时,会优先选择 2MB 大小的透明大页面,而不是 4KB 的常规页面。这一点我们可以轻易验证,比如下图中显示了透明大页面的瞬时数量。在峰值时,我们看到约 34,000 个 THP,即约 68GB 的内存量。

技术图片

 

我们还观察到,THP 的数量一开始很高,一段时间后开始下降。这是因为某些 THP 被拆分成小的常规页面,以补充可用内存的不足。

为什么需要拆分大页面呢?是因为当 Linux 在有内存压力时,它会将 THP 分为常规的、要准备交换的页面。为什么必需拆分大页面?这是因为当前的 Linux,仅支持常规大小页面的交换。

拆分活动的数量我们也用下图画出来了。你可以看到,在五分钟内大约有 5K 个 THP 页面被拆分,对应于 10GB 的内存。

技术图片

 

除了大页面拆分,同时,Linux 也会尝试将常规页面重新聚合为 THP 大页面,这就需要额外的页面扫描,并消耗 CPU。如果你在实践中注意观察的话,可以发现这种活动会占用大量 CPU。

使用 THP 可能遇到的更糟糕的情况是,聚合和拆分这两个相互矛盾的活动,是来回执行的。也就是说,当系统承受内存压力时,THP 被拆分成常规页面,而不久之后,常规页面则又被聚合成 THP,依此类推。我们已经观察到,这种行为会严重损害我们生产系统中的应用程序性能。

如何解决多程序互相干扰?

那么程序在启动和运行时互相干扰的性能问题,到底该怎么解决呢?我们现在就来看解决方案。

我们的解决方案由三个设计元素组成,每个设计元素都针对问题的特定方面。部署任何单独的元素都将在一定程度上对问题有所帮助。但是,所有设计元素协同工作,才能获得最好的效果。

第一个设计元素是预分配 JVM 的堆空间。

我们知道,对 JVM 而言,只有在实际使用堆空间之时,就是当需要增大堆空间来容纳新对象分配请求时,Linux 才会为之分配新的内存页面,这时就可能会触发大量页面回收,并损害程序和系统性能。

这个设计元素就是预分配所有堆空间,从而避免了 Linux 实时分配页面的不利场景。要预先执行堆预分配,需要使用一个特殊的 JVM 参数:“ -XX:+ AlwaysPreTouch”,来启动 Java 应用程序。

但这个设计元素也有副作用,就是增加了 JVM 启动所需的时间,在部署时你需要考虑这一点。我们也做过一些实际测量,这个额外启动时间并不大,一般在几秒钟内,通常是可以接受的。

第二个设计元素,是关于如何保护 JVM 的堆空间不被唤出到外部存储。

我们知道,当发生 GC 时,JVM 需要扫描相应的内存页。如果这些页面被操作系统换出到外部存储,则需要先换入它们到内存,这就会导致延迟,会增加 JVM 的暂停时间。

这个设计元素就可以防止 JVM 的堆页面被换出。 我们知道,Linux 操作系统上是可以关闭内存页面交换的,但是这个设置如果是在系统级别进行,就会影响所有应用程序和所有内存空间。我推荐你一个更好的实现,就是采用微调,你来选择哪个应用程序和哪个存储区域可以页面交换。例如,你可以使用 cgroup 来精确控制要交换的应用程序。

公司中的大多数平台,一般都用来运行同类 Java 应用程序;这些程序往往配置差不多。在这些情况下,在系统级别关闭应用程序交换,倒也是非常合理的。

第三个设计元素是动态调整 THP。

我们已经看到,启用 THP 功能可能会在某些场景下,导致严重的性能损失;但是 THP 在其他场景的确提高了性能,所以到底是否要启用 THP 呢?我们需要仔细考虑。

当 THP 影响性能时,系统的可用内存往往也恰好严重不足。发生这种情况时,现有的 THP需要拆分成常规页面以进行页面换出。所以,我建议你用一个可用内存大小的阈值来决定THP 的开关。

具体来说,就是建议你使用应用程序的堆大小作为内存阈值,来决定是否打开或关闭THP。当可用内存远远大于应用程序的内存可能占用量大小时,就启用 THP,因为系统不

太可能在启动特定应用程序后出现内存压力。否则的话,就关闭 THP。

由于许多后端服务器都是运行同类应用程序,通常情况下,你都很容易知道,部署的应用程序预期会占用多少内存空间。

此外,常规页面需要聚合成 THP,才能将大页面分配给应用程序。因此,这个元素的另外一部分机制是进行微调,是决定何时允许 THP 聚合。我建议你根据操作系统的直接页面扫描率和聚合进程的 CPU 使用率来决定。

总结

今天我们讲述了,将多个应用程序放置在同一台服务器上时,由于应用程序和操作系统机制的互相作用,引发的一系列性能问题。这些问题的根本原因,就是程序之间的互相影响。

技术图片

 

应用程序之间的关系和人际关系一样,有时和谐,有时不和谐。应用程序之间的关系,甚至程序和操作系统及硬件之间的关系,也会很复杂,也需要做足够的性能分析,才能理清它们之间的关系。

程序员诺禾:诺禾分析多任务中的java性能问题

标签:作用   原因   地址转换   img   指标   java   java性能   系统   can   

原文地址:https://www.cnblogs.com/lovenuohe/p/13020412.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!