不明觉厉！线上部署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里读取数据了，完全依托内存来走，那你的性能必然是毫秒级的，不可能出现几秒钟才完成一个查询的情况。
整个过程，如下图所示：
所以说，建议大家在线上生产系统引入任何技术的时候，都应该先对这个技术的原理，甚至源码进行深入的理解，知道他具体的工作流程是什么，然后针对性的合理设计生产环境的部署方案，保证最佳的生产性能。
END
如有收获，请划至底部，点击“ 在看 ”，谢 谢 ！
扫描下方海报二维码，试听课程：
欢迎长按下图关注公众号 石杉的架构笔记
BAT架构经验倾囊相授
正文到此结束
热门推荐
相关文章
近期评论
-
666
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
