生产实践经验：线上系统的 JVM 内存是越大越好吗？

超、凢脫俗 2022-12-15 02:57 218阅读 0赞

![format_png][]

我的新课《C2C 电商系统微服务架构120天实战训练营》在公众号**儒猿技术窝**上线了，感兴趣的同学，可以长按扫描下方二维码了解课程详情：

**课程大纲请参见文末**

![format_png 1][]

![format_png 2][]

--------------------

“ 这篇文章，给大家聊一个生产环境的实践经验：线上系统部署的时候，**JVM堆内存大小是越大越好吗**？

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

![format_png 3][]

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

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

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

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

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

大家看下面的示意图。

![format_png 4][]

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

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

![format_png 5][]

2、依赖Java系统自身内存有什么缺陷

如果用类似上述的方式，依赖Java系统自身内存处理数据，比如说设计一个内存缓冲区，来缓冲住高并发写入的大量消息，那么是有其缺陷的。最大的缺陷，其实就是JVM的GC问题，这个GC就是垃圾回收，这里简单说一下他是怎么回事。

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

那么写入磁盘之后，这些数据还需要继续放在内存里吗？明显是不需要的了，此时就会依托JVM垃圾回收机制，把内存里那些不需要的数据给回收掉，释放掉那些内存空间腾出来。

但是JVM垃圾回收的时候，有一种情况叫做stop the world，就是他会停止你的工作线程，就专门让他进行垃圾回收。这个时候，他在垃圾回收的时候，有可能你的这个中间件系统就运行不了了。

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

![format_png 6][]

虽然说现在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的运行流程。

![format_png 7][]

然后比如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里读，谁让你os cache里就只能放的下10G的一半大小的数据啊，另外一半都在磁盘里，这也是没办法的，如下图。

![format_png 8][]

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

所以很多人在用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里读取数据了，完全依托内存来走，那你的性能必然是毫秒级的，不可能出现几秒钟才完成一个查询的情况。

整个过程，如下图所示：

![format_png 9][]

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

**END**

*征稿：愿意技术分享的朋友，欢迎投稿，每篇文章提供 800 ~ 1000 元的稿酬*

*投稿请扫描下方二维码，添加微信：jeversoncui*

![format_png 10][]

![format_png 11][]

![format_png 12][]

![format_png 13][]

![format_png 14][]

[format_png]: /images/20221123/f121e5ed9ad04aae88e63e9a2f268c06.png
[format_png 1]: /images/20221123/7f4e78b340ef49faab9c2eeb6c35ba00.png
[format_png 2]: /images/20221123/1b81bfe234b244328f78eddeed9e3e38.png
[format_png 3]: /images/20221123/41550e8f23624682a4a9597e0e10379d.png
[format_png 4]: /images/20221123/8b900bbd21c34fbe963a4464aca96df8.png
[format_png 5]: /images/20221123/a57600d1153947a9b4ec672ab6e290f8.png
[format_png 6]: /images/20221123/30dd4d8e004143df8e796be67bf201fe.png
[format_png 7]: /images/20221123/98b7e90be5a6433e9d7a9f39696f6a1d.png
[format_png 8]: /images/20221123/a972d0089b934c6994a7c20d52c03a0d.png
[format_png 9]: /images/20221123/f94d568ad5fd480baf981c8b67ee1f25.png
[format_png 10]: /images/20221123/5ed45c273dd14f98a19250d59cb2827d.png
[format_png 11]: /images/20221123/1a5a683832e44b2da555e3e3f0392e0b.png
[format_png 12]: /images/20221123/b0f5b407984c4525885d6261d496a32d.png
[format_png 13]: /images/20221123/8b12af10341a464b9370a40a5c225174.png
[format_png 14]: /images/20221123/84fa109e71004f81a24150cb5487a93d.png