我有一个庞大的弹性搜索集群，其中包含10个以上的数据节点，并且托管着超过3000万个文档的多个索引。
现在要解决此群集上的性能问题，我开始查看一些索引的慢日志，并在奇怪的地方注意到以下内容：
类型[estype]，统计信息[]，search_type [QUERY_THEN_FETCH]，总计碎片[48]，，
我的慢速日志显示它击中48个分片，这对我的索引来说是不可能的，因为它有6个具有3个副本的主分片，并且如搜索类型中所述，它是普通的搜索查询，据我了解，对于搜索查询， ES会将请求发送到主分片或副本分片，但不会同时发送给两者。
因此，根据此逻辑，它应该命中最大值，最多6个分片，即使我认为它命中了所有分片（包括副本），它也可以最大为6 * 4 = 24个分片，那么怎么来我的慢日志记录为48，这使我对这些查询的慢感到怀疑。
注意：-如果我只是从慢速日志中获取ES查询并直接使用kopf或curl命中，作为响应，它仅显示正确的6个分片。
答案 0 :(得分：0)
找到了原因，实际上在我们的应用程序中，我们创建了一个单独的基于语言的索引，并且它们具有相同的配置（没有分片和副本）。
当我签入我的应用程序时，总共有8个基于语言的索引（每个索引都有6个主要分片）。
我们发送给ES的查询使用索引名称中的（*），我们将索引名称模式设置为indexprefix_lang，因此foo_en，foo_gb，foo_es依此类推，因此通过在索引前缀中指定*就像这里{ {1}} 我们达到了所有索引。产生了8 * 6 = 48个分片。
造成混淆的原因是，除英语以外的其他基于语言的索引的文档数量很少，并且未超过我们设置的慢查询阈值，并且以慢查询日志格式显示的索引名称为{ {1}}，但它显示整个查询的total_shards（与索引无关），在这种情况下为48。