标签：Disruptor 一次 后续 oom Jraft 队列 内存 size

说明

本文是接上一篇oom记录文章《一次oom我做了什么-（JVM，JMAP，MAT，等，大杂烩）》，后续又发现了一些问题，再追加的一些记录。

回顾

之前出oom问题分析的有些笼统，并且不太准确，之前用mat分析后得出是LogManager这个类相关的问题，确实，这个类是出现oom的原因之一，但不是根本原因，真正的原因是截图中圈出来的Disruptor，不仅在LogManager中出现了，而且在NodeImpl中也出现了。

分析

Disruptor是一个高并发无锁的环形队列，我们采用的是Jraft来做数据同步，而Disruptor正是Jraft中引用的，并且我在Jraft文档中看到，如果是写入吞吐量较高的应用，建议将Disruptor的size调大，Jraft中默认是16384。基于我们的业务场景，想当然的就把16384又扩大了二倍。
那么问题来了，这个size和oom有什么关系？
环形队列的逻辑是队列中数据量到达了设定的阈值后，新进入的将会覆盖原数据，就像一个环一样。
这样的逻辑，队列中的数据量是固定的，最大内存应该也是固定的才对，进来再多数据，只要到了阈值，应该就不会再占用更多内存了，那为何会oom呢？
因为我们设定的业务逻辑，是合并请求，然后一次提交大量数据交给raft来同步，这样是为了减少rpc次数，提高效率，但同时又扩大了每笔提交数据量，所以这个环形队列在我们这个逻辑中就很尴尬了，还没有到16384，可能size还很小但时候，内存已经撑爆了。
于是我们尝试着平衡合并请求的阈值与Disruptor的size，经过大量压测并监控内存使用情况，最终这样平衡，可以解决我们oom的问题。

标签：Disruptor,一次,后续,oom,Jraft,队列,内存,size
来源： https://blog.csdn.net/weixin_44607611/article/details/111193426

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。