绑定完请刷新页面
取消
刷新

分享好友

×
取消 复制
不明觉厉!线上部署Kafka和ES,为啥JVM堆内存分配越大,性能反而越低?
2020-05-28 16:27:06

作者:中华石杉

出自:微信公众号“石杉的架构笔记”

原文:不明觉厉!线上部署Kafka和ES,为啥JVM堆内存分配越大,性能反而越低?


本文给大家聊一个生产环境的实践经验:线上系统部署的时候,JVM堆内存大小是越大越好吗

先说一个前提,本文主要讨论Kafka和Elasticsearch两种分布式系统的线上部署情况,不是普通的Java应用系统

1、是否依赖Java系统自身内存处理数据?

先说明一点,不管是我们自己开发的Java应用系统,还是一些中间件系统,在实现的时候都需要选择是否基于自己Java进程的内存来处理数据。

大家应该都知道,Java、Scala等编程语言底层依赖的都是JVM,那么只要是使用JVM,就可以考虑在JVM进程的内存中来放置大量的数据。

还是给大家举个例子,大家应该还记得之前聊过消息中间件系统。

比如说系统A可以给系统B发送一条消息,那么中间需要依赖一个消息中间件,系统A要先把消息发送到消息中间件,然后系统B从这个消息中间件消费到这条消息。


大家看下面的示意图:


大家应该都知道,一条消息发送到消息中间件之后,有一种处理方式,就是把这条数据先缓冲在自己的JVM内存里。

然后过一段时间之后,再从自己的内存刷新到磁盘上去,这样可以持久化保存这条消息,如下图。


2、依赖Java系统自身内存的缺陷

如果用类似上述的方式,依赖Java系统自身内存处理数据,比如说设计一个内存缓冲区,来缓冲住高并发写入的大量消息,那么是有其缺陷的。

大的缺陷,其实就是JVM的GC问题,这个GC就是垃圾回收,这里简单说一下他是怎么回事。

大家可以想一下,如果一个Java进程里老是塞入很多的数据,这些数据都是用来缓冲在内存里的,但是过一会儿这些数据都会写入磁盘。

那么写入磁盘之后,这些数据还需要继续放在内存里吗?

明显是不需要的了,此时就会依托JVM垃圾回收机制,把内存里那些不需要的数据给回收掉,释放掉那些内存空间腾出来。

但是JVM垃圾回收的时候,有一种情况叫做stop the world,就是他会停止你的工作线程,就专门让他进行垃圾回收。

这个时候,他在垃圾回收的时候,有可能你的这个中间件系统就运行不了了。

比如你发送请求给他,他可能都没法响应给你,因为他的接收请求的工作线程都停了,现在人家后台的垃圾回收线程正在回收垃圾对象。


大家看下图:


虽然说现在JVM的垃圾回收器一直在不断的演进和发展,从CMS到G1,尽可能的在降低垃圾回收的时候的影响,减少工作线程的停顿。

但是你要是完全依赖JVM内存来管理大量的数据,那在垃圾回收的时候,或多或少总是有影响的。

所以特别是对于一些大数据系统,中间件系统,这个JVM的GC(Garbage Collector,垃圾回收)问题,真是头疼的一个问题。



3、优化为依赖OS Cache而不是JVM

所以类似Kafka、Elasticsearch等分布式中间件系统,虽然也是基于JVM运行的,但是他们都选择了依赖OS Cache来管理大量的数据。

也就是说,是操作系统管理的内存缓冲,而不是依赖JVM自身内存来管理大量的数据。

具体来说,比如说Kafka吧,如果你写一条数据到Kafka,他实际上会直接写入磁盘文件。

但是磁盘文件在写入之前其实会进入os cache,也就是操作系统管理的内存空间,然后过一段时间,操作系统自己会选择把他的os cache的数据刷入磁盘。

然后后续在消费数据的时候,其实也会优先从os cache(内存缓冲)里来读取数据。

相当于写数据和读数据都是依托于os cache来进行的,完全依托操作系统级别的内存区域来进行,读写性能都很高。

此外,还有另外一个好处,就是不要依托自身JVM来缓冲大量的数据,这样可以避免复杂而且耗时的JVM垃圾回收操作。

大家看下面的图,其实就是一个典型的Kafka的运行流程。


然后比如Elasticsearch,他作为一个现在流行的分布式搜索系统,也是采用类类似的机制。

大量的依赖os cache来缓冲大量的数据,然后在进行搜索和查询的时候,也可以优先从os cache(内存区域)中读取数据,这样就可以保证非常高的读写性能。


4、经验之谈

依赖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里读,如下图所示:


那此时你有一半的请求都是从磁盘上在读取数据,必然会导致性能很差。

所以很多人在用Elasticsearch的时候就是这样的一个问题,老是觉得ES读取速度慢,几个亿的数据写入ES,读取的时候要好几秒。

那能不花费好几秒吗?你要是ES集群部署的时候,给JVM内存过大,给os cache留了几个GB的内存,导致几亿条数据大部分都在磁盘上,不在os cache里,后读取的时候大量读磁盘,耗费个几秒钟是很正常的。


5、正确的做法

针对场景合理给os cache更大内存

所以说,针对类似Kafka、Elasticsearch这种生产系统部署的时候,应该要给JVM比如6GB或者几个GB的内存就可以了。

因为他们可能不需要耗费过大的内存空间,不依赖JVM内存管理数据,当然具体是设置多少,需要你精准的压测和优化。

但是对于这类系统,应该给os cache留出来足够的内存空间

比如32GB内存的机器,完全可以给os cache留出来20多G的内存空间,那么此时假设你这台机器总共就写入了20GB的数据,就可以全部驻留在os cache里了。

然后后续在查询数据的时候,不就可以全部从os cache里读取数据了,完全依托内存来走,那你的性能必然是毫秒级的,不可能出现几秒钟才完成一个查询的情况。


整个过程,如下图所示:

所以说,建议大家在线上生产系统引入任何技术的时候,都应该先对这个技术的原理,甚至源码进行深入的理解,知道他具体的工作流程是什么,然后针对性的合理设计生产环境的部署方案,保证佳的生产性能。


经典Java零基础教程

Java基础、入门、精通、架构师全套资源shimo.im图标

推荐阅读:

java钢铁侠-马克51号:面试官:你简历中写用过docker,能说说容器和镜像的区别吗?zhuanlan.zhihu.com图标

分享好友

分享这个小栈给你的朋友们,一起进步吧。

Kafka
创建时间:2020-05-22 09:55:12
Kafka是由Apache软件基金会开发的一个开源流处理平台,由Scala和Java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统,它可以处理消费者规模的网站中的所有动作流数据。 这种动作(网页浏览,搜索和其他用户的行动)是在现代网络上的许多社会功能的一个关键因素。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。 对于像Hadoop的一样的日志数据和离线分析系统,但又要求实时处理的限制,这是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理,也是为了通过集群来提供实时的消息。
展开
订阅须知

• 所有用户可根据关注领域订阅专区或所有专区

• 付费订阅:虚拟交易,一经交易不退款;若特殊情况,可3日内客服咨询

• 专区发布评论属默认订阅所评论专区(除付费小栈外)

栈主、嘉宾

查看更多
  • ?
    栈主

小栈成员

查看更多
  • wangdabin1216
  • 小雨滴
  • chenglinjava0501
  • 时间不说话
戳我,来吐槽~