面试官: 你们生产环境的JVM怎么设置的?

这篇文章,给大家聊一个生产环境的实践经验:线上系统部署的时候,JVM堆内存大小是越大越好吗,先说明白一个前提,本文主要讨论的是Kafka和Elasticsearch两种分布式系统的线上部署情况,不是普通的Java应用系统。,先说明一点,不管是我们自己开发的Java应用系统,还是一些中间件系统,在实现的时候都需要选择是否基于自己Java进程的内存来处理数据。,大家应该都知道,Java、Scala等编程语言底层依赖的都是JVM,那么只要是使用JVM,就可以考虑在JVM进程的内存中来放置大量的数据。,还是给大家举个例子,大家应该还记得之前聊过消息中间件系统。,比如说系统A可以给系统B发送一条消息,那么中间需要依赖一个消息中间件,系统A要先把消息发送到消息中间件,然后系统B从这个消息中间件消费到这条消息。,大家看下面的示意图。,
,面试官: 你们生产环境的JVM怎么设置的?,大家应该都知道,一条消息发送到消息中间件之后,有一种处理方式,就是把这条数据先缓冲在自己的JVM内存里。,然后过一段时间之后,再从自己的内存刷新到磁盘上去,这样可以持久化保存这条消息,如下图。,面试官: 你们生产环境的JVM怎么设置的?,如果用类似上述的方式,依赖Java系统自身内存处理数据,比如说设计一个内存缓冲区,来缓冲住高并发写入的大量消息,那么是有其缺陷的。,最大的缺陷,其实就是JVM的GC问题,这个GC就是垃圾回收,这里简单说一下他是怎么回事。,大家可以想一下,如果一个Java进程里老是塞入很多的数据,这些数据都是用来缓冲在内存里的,但是过一会儿这些数据都会写入磁盘。,那么写入磁盘之后,这些数据还需要继续放在内存里吗?,明显是不需要的了,此时就会依托JVM垃圾回收机制,把内存里那些不需要的数据给回收掉,释放掉那些内存空间腾出来。,但是JVM垃圾回收的时候,有一种情况叫做stop the world,就是他会停止你的工作线程,就专门让他进行垃圾回收。,这个时候,他在垃圾回收的时候,有可能你的这个中间件系统就运行不了了。,比如你发送请求给他,他可能都没法响应给你,因为他的接收请求的工作线程都停了,现在人家后台的垃圾回收线程正在回收垃圾对象。,大家看下图。,
,面试官: 你们生产环境的JVM怎么设置的?,虽然说现在JVM的垃圾回收器一直在不断的演进和发展,从CMS到G1,尽可能的在降低垃圾回收的时候的影响,减少工作线程的停顿。,但是你要是完全依赖JVM内存来管理大量的数据,那在垃圾回收的时候,或多或少总是有影响的。,所以特别是对于一些大数据系统,中间件系统,这个JVM的GC(Garbage Collector,垃圾回收)问题,真是最头疼的一个问题。,所以类似Kafka、Elasticsearch等分布式中间件系统,虽然也是基于JVM运行的,但是他们都选择了依赖OS Cache来管理大量的数据。,也就是说,是操作系统管理的内存缓冲,而不是依赖JVM自身内存来管理大量的数据。,具体来说,比如说Kafka吧,如果你写一条数据到Kafka,他实际上会直接写入磁盘文件。,但是磁盘文件在写入之前其实会进入os cache,也就是操作系统管理的内存空间,然后过一段时间,操作系统自己会选择把他的os cache的数据刷入磁盘。,然后后续在消费数据的时候,其实也会优先从os cache(内存缓冲)里来读取数据。,相当于写数据和读数据都是依托于os cache来进行的,完全依托操作系统级别的内存区域来进行,读写性能都很高。,此外,还有另外一个好处,就是不要依托自身JVM来缓冲大量的数据,这样可以避免复杂而且耗时的JVM垃圾回收操作。,大家看下面的图,其实就是一个典型的Kafka的运行流程。,面试官: 你们生产环境的JVM怎么设置的?,然后比如Elasticsearch,他作为一个现在最流行的分布式搜索系统,也是采用类类似的机制。,大量的依赖os cache来缓冲大量的数据,然后在进行搜索和查询的时候,也可以优先从os cache(内存区域)中读取数据,这样就可以保证非常高的读写性能。,依赖os cache的系统JVM内存越大越好?,所以现在就可以进入我们的主题了,那么比如就以上述说的kafka、elasticsearch等系统而言,在线上生产环境部署的时候,你知道他们是大量依赖于os cache来缓冲大量数据的。,那么,给他们分配JVM堆内存大小的时候是越大越好吗?,明显不是的,假如说你有一台机器,有32GB的内存,现在你如果在搞不清楚状况的情况下,要是傻傻的认为还是给JVM分配越大内存越好,此时比如给了16G的堆内存空间给JVM,那么os cache剩下的内存,可能就不到10GB了,因为本身其他的程序还要占用几个GB的内存。,那如果是这样的话,就会导致你在写入磁盘的时候,os cache能容纳的数据量很有限。,比如说一共有20G的数据要写入磁盘,现在就只有10GB的数据可以放在os cache里,然后另外10GB的数据就只能放在磁盘上。,此时在读取数据的时候,那么起码有一半的读取请求,必须从磁盘上去读了,没法从os cache里读,谁让你os cache里就只能放的下10G的一半大小的数据啊,另外一半都在磁盘里,这也是没办法的,如下图。,面试官: 你们生产环境的JVM怎么设置的?,那此时你有一半的请求都是从磁盘上在读取数据,必然会导致性能很差。,所以很多人在用Elasticsearch的时候就是这样的一个问题,老是觉得ES读取速度慢,几个亿的数据写入ES,读取的时候要好几秒。,那能不花费好几秒吗?你要是ES集群部署的时候,给JVM内存过大,给os cache留了几个GB的内存,导致几亿条数据大部分都在磁盘上,不在os cache里,最后读取的时候大量读磁盘,耗费个几秒钟是很正常的。,针对场景合理给os cache更大内存,所以说,针对类似Kafka、Elasticsearch这种生产系统部署的时候,应该要给JVM比如6GB或者几个GB的内存就可以了。,因为他们可能不需要耗费过大的内存空间,不依赖JVM内存管理数据,当然具体是设置多少,需要你精准的压测和优化。,但是对于这类系统,应该给os cache留出来足够的内存空间,比如32GB内存的机器,完全可以给os cache留出来20多G的内存空间,那么此时假设你这台机器总共就写入了20GB的数据,就可以全部驻留在os cache里了。,然后后续在查询数据的时候,不就可以全部从os cache里读取数据了,完全依托内存来走,那你的性能必然是毫秒级的,不可能出现几秒钟才完成一个查询的情况。,整个过程,如下图所示:,面试官: 你们生产环境的JVM怎么设置的?,所以说,建议大家在线上生产系统引入任何技术的时候,都应该先对这个技术的原理,甚至源码进行深入的理解,知道他具体的工作流程是什么,然后针对性的合理设计生产环境的部署方案,保证最佳的生产性能。

文章版权声明

 1 原创文章作者:cmcc,如若转载,请注明出处: https://www.52hwl.com/18813.html

 2 温馨提示:软件侵权请联系469472785#qq.com(三天内删除相关链接)资源失效请留言反馈

 3 下载提示:如遇蓝奏云无法访问,请修改lanzous(把s修改成x)

 免责声明:本站为个人博客,所有软件信息均来自网络 修改版软件,加群广告提示为修改者自留,非本站信息,注意鉴别

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023年3月5日 上午12:00
下一篇 2023年3月7日 下午10:34