【发布时间】：2013-12-24 23:11:52
【问题描述】：
我有一个 3 节点集群，每个节点都有 4g ES_HEAP_SIZE。当索引大小在 4GB 左右时没有问题，但是当索引大小超过 10GB 时，经常会出现 Java 堆空间异常和 Unavailableshard 异常。当我减小索引大小时，问题就消失了。因此我的问题是；这样一个 3 节点的 elasticsearch 集群的最佳索引大小是多少？
【问题讨论】：
【发布时间】：2013-12-24 23:11:52
【问题描述】：
“x-node 集群的最佳索引大小是多少”的问题取决于以下几点：
您商店中的平均文档有多大？
您的查询是什么样的，您是否进行了大量的分面/排序？
每台机器上的总内存是多少？这些节点是在不同的机器上还是在同一台机器上？
当您索引数据时，您是否设置了 store=true ？ （你不应该）
您是否在做其他事情，例如占用大量内存的父/子文档或嵌套文档？
您的索引是重度还是轻度？
您商店中的文档总数是多少？
在您的情况下，它与索引大小无关，更多的是为您的情况分配适量的内存。此外，我认为您无需真正询问即可根据当前的使用和存储模式找到了自己的最佳尺寸。
也就是说，上面列出的项目只是我在尝试衡量应该分配给 JVM 多少内存时应该使用的一些东西。
一般来说，您应该始终将至少 50% 的空间留给操作系统，并且永远不要超过 32GB（我永远不会超过 29GB）。除此之外，我不会说有一个硬性规定。在您的情况下，您可能会发现还有空间可以分配更多，或者您可能会发现分配过多。
例如，假设您有一个要分面的字段，该字段是一个长数组。
假设最长的这样的数组有 300 个成员，而您正在查看 2M 文档。 JVM 将首先分配 300*2000000*8（java long 为 8 个字节）。如果该空间量超过了您的 JVM 大小，那么您每次都会得到一个 OOM。
这里的解决方案是 A.) 创建第四个节点 B.) 分配更多内存 C.) 重新考虑索引/存储策略或 D.) 重新考虑分面策略。
例如，也许您可以使用 short 或 int。也许你不需要所有 300 个成员，但你真的只关心三个来分面。只存储这三个，长长的 300 个列表转到另一个字段（您永远不会面对）。
通常该策略取决于用例，并且需要对您将如何使用搜索集群进行一些思考和预见。 elasticsearch 最大的优点之一是您可以在大约五分钟内启动并运行，但我发现这导致了一种错觉，即 elasticsearch 管理一切。它管理了很多，但这仍然不能免除良好的系统管理。
【讨论】：