我有一个3节点集群，其节点每个节点有4g ES_HEAP_SIZE。当索引大小大约为4GB时没有问题，但是当索引大小超过10GB时，它通常会给Java堆空间异常和Unavailableshard异常。当我减小索引大小时，问题就消失了。因此我的问题是;这种3节点弹性搜索集群的最佳索引大小是多少？
答案 0 :(得分：5)
“x节点集群的最佳索引大小是什么”的问题取决于以下几点：
商店中的普通文件有多大？
您的查询是什么样的，您是否进行了大量的分面/排序？
每台机器的总内存是多少？这些节点是在单独的机器上还是在同一台机器上？
索引数据时，是否存储= true set？ （你不应该）
您正在做其他事情，例如内存密集的父/子或嵌套文档吗？
您是重度还是轻度索引？
商店中的文件总数是多少？
在您的情况下，它不是关于索引大小，而是关于为您的案例分配适当数量的内存。此外，我认为您根据当前的使用和存储模式找到了自己的最佳尺寸，而没有真正询问。
也就是说，上面列出的项目只是我在试图判断应该为JVM分配多少内存时应该使用的一些内容。
一般情况下，您应该始终将至少50％留给操作系统，而不要超过32GB（我永远不会超过29GB）。除此之外，我不会说有一条硬性规则。在您的情况下，您可能会发现有更多空间可以分配，或者您可能会发现分配的内容过多。
例如，假设您有一个面向的字段，该字段是一个long数组。
让我们说最长的阵列有300个成员，你正在查看2M文档。 JVM将首先分配300 * 2000000 * 8（java长度为8个字节）。如果该空间量超过了JVM大小，则每次都会获得一个OOM。
此处的解决方案是A.）创建第四个节点B.）分配更多内存C.）重新考虑您的索引/存储策略或D.）重新考虑您的分面策略。
例如，也许你可以使用short或int。也许你不需要所有300名成员，但你真的只关心三个人的分面。只存储那三个，300个长列表将转到另一个领域（你永远不会反对）。
通常，策略是依赖于用例的，需要一些思考和预测，以了解如何使用搜索群集。弹性搜索最大的好处之一就是你可以在大约五分钟内启动并运行，但我发现这导致了弹性搜索管理一切的错觉。它管理很多，但这仍然不能免除良好的系统管理。