“ 这篇文章，给大家聊一个生产环境的实践经验：线上系统部署的时候，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里读，谁让你os cache里就只能放的下10G的一半大小的数据啊，另外一半都在磁盘里，这也是没办法的，如下图。
那此时你有一半的请求都是从磁盘上在读取数据，必然会导致性能很差。
所以很多人在用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
标签：越大越,os,cache,内存,JVM,磁盘,数据 来源： https://blog.51cto.com/u_11475121/2957230
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。