搜索响应时间不定时增加了一倍

我们的系统最近面临CPU使用率高峰，其原因仍然未知。过去我们遇到了高内存使用率和磁盘警报，因为我们每天都在运行批量索引的夜间工作，更新了几乎所有的文档。但高CPU使用率不成问题。搜索响应时间不定时增加了一倍

迄今收集的数据：

节点03（出6个数据节点和3主）从高CPU使用（> 95％）所受5分钟，得到在1秒的响应时间尖峰，而平均响应时间是40毫秒。查看指标，给定高CPU节点上的索引计数有轻微波动，同时Young GC出现轻微波动（尽管在两种情况下都没有出现峰值）。

我不排除大量索引，因为我们确实有一位卡夫卡消费者在任何时间接受大量索引数据，但是它的速度控制在每秒250个文档，每个时间间隔为250 ms批量呼叫。

此外，热线程端点确实提供了一些数据，但我无法破译它。

Hot threads

更新

更新了问题的标题，因为以前的意见是错误的。主要问题是响应时间增加了一倍，并且CPU使用率并不高，因为一段时间后使用情况已经稳定下来

已经有一些发展。在秒杀之后，CPU使用率逐渐下降并且正常。但是，我们的响应时间始终保持在100-250毫秒之间（平均值为35-100毫秒）。

当前响应中存在接近齿锯（不完全一致的齿锯）模式。

而且，在老GC计数小凸点秒杀时有发生。

在节点统计信息中未发现任何异常。将在找到时更新。仍在张贴调查。

node stats

还发布了近期的热点话题 -

hot_thread_2

来源

2016-09-21 Utkarsh Mishra

如果您有权访问日志，请检查您在CPU峰值期间运行的查询类型。排序结果是Cpu密集型的。您可能正在运行返回大量结果的查询。只是猜测... – jay

@jay我们有一个硬编码结果大小值的业务逻辑设置。还检查了任何分析日志。找不到任何东西。 –

所有热门主题都与搜索有关。在秒杀期间你有没有热线转储？你的查询有没有改变？聚合？如果您在这些服务器上有任何监控设置，您是否可以检查Node 03在峰值时是否正在经历严重合并？ – jay

节点03肯定似乎已经经历了沉重的索引。

   "bulk": { 
       "threads": 8, 
       "queue": 0, 
       "active": 0, 
       "rejected": 0, 
       "largest": 8, 
       "completed": 9528532

我比较节点04的统计与节点03.一些事情，我注意到在03

4144165个文档，但256087749（index_total）建立索引的请求？
只有节点03有41个open_contexts。所以当你使用这个数据时，它有41个搜索请求。所有其他节点都是0。
与其他节点相比，节点03和节点01的合并数量非常高。

您是否有任何路由逻辑将特定文档发送到特定节点？或者可能这些节点包含更频繁更新的索引？

当你看到尖峰时，你还有什么机会对节点03上的索引进行优化？查看节点统计信息，03是唯一具有“完成”优化的节点

"optimize": { 
       "threads": 1, 
       "queue": 0, 
       "active": 0, 
       "rejected": 0, 
       "largest": 1, 
       "completed": 1 
      },

另外，您的refresh_interval是什么？ ES中的默认值是1秒。批量索引时可能会触发大量合并。

来源

2016-09-21 23:30:30 jay

索引请求数量的增加可能是因为我们的午夜工作几乎全部更新了我们的文档。此外，我们目前没有逻辑路由搜索请求。目前，我们将所有搜索请求发送到前3个节点。此外，我们的批量索引主要在午夜时间运行，如果搜索响应在此期间上升，我们也可以。当前的refresh_interval设置为1秒。 –

关于路由问题。我怀疑只有1个节点会收到所有的搜索请求。虽然我们没有合适的路由逻辑，但我们的应用服务器会根据可用性向节点发送请求。即便如此，我们没有尽可能多的搜索请求来控制任何单个节点。 –

搜索响应时间不定时增加了一倍

回答

相关问题