我一直在为电子商务网站使用elasticseArch – 不仅用于搜索,还用于检索产品数据(/ index / tyPE / {id})以避免SQL查询.

@H_404_8@

通常这种方法非常有效,大多数请求在1ms到3ms之间得到解答.但有一些请求需要100ms-250ms – 仅用于/ index / type / {id}这样的GET请求,其中没有进行实际搜索,通常需要1-2ms.在我看来,如果这样的响应需要超过100毫秒,那肯定是错误的,因为服务器有很多Ram和一个快速的6核cpu,数据存储在速度非常快的SSD上,只有150’000个条目(Elasticsearch大约300MB)并且几乎没有负载. Elasticsearch有5GB的RAM,并且Lucene有足够的备用RAM来一直缓存所有条目.请求通过具有专用交换机的本地网络进行.索引只有一个分片,我正在运行Elasticsearch 2.3.@H_404_8@

我正在用PHP做请求.我已经尝试使用Nginx作为Elasticsearch的反向代理,但是这并没有解决任何问题 – 它发生在Nginx之间和没有Nginx之间.@H_404_8@

编辑：约1％的时间发生缓慢请求(与请求总数相关).我也可以通过在Elasticsearch中将1000个请求用PHP转换为/ index / type / {id}来重现它 – 总是1％会非常慢,即使使用相同的ID如/ index / type / 55(只要ID存在).这也意味着没有“缓存效应” – 在第一次请求之后Elasticsearch应该将数据“准备好”,但无论我请求什么ID或者我一遍又一遍地请求相同的ID,慢速请求的数量都是相同的.@H_404_8@

EdIT2：我看过Marvel&节点的节点统计数据Kibana,没有任何迹象表明那里有减速：使用了20-40％的JVM堆内存,几乎没有延迟(0.1ms到0.5ms之间).它确认有足够的资源,我看不到任何缓慢请求的原因的相关性或提示.@H_404_8@

经过大量测试：@H_404_8@

这些现在是我明确的测试结果：@H_404_8@

> Elasticsearch的响应越大,发生缓慢请求的可能性就越大.许多小的响应比一个大的响应有更大的机会不会特别慢.
>使用简单的GET请求轰炸Elasticsearch可以减少并行运行更多请求时响应速度慢的可能性.
>当一次又一次地使用简单搜索一个关键字时,Elasticsearch在响应中告诉我它“花了”2-3ms,即使响应需要200ms直到我的应用程序收到它.但也在这里：响应越大,响应速度越慢的可能性越大.当我运行请求循环时,1KB响应永远不会慢,2.5KB在极少数情况下只有一点点慢(30ms),10KB响应总是有高达1％的慢速请求,最多200ms.@H_404_8@

我已经考虑到它可能是一个网络“问题”,特别是当Elasticsearch认为它很快时,即使它很慢.但这将是一个奇怪的根本原因,因为我的设置非常标准(Debian Jessie).此外,保持活动连接和TCP_NODELAY不会改善此问题.@H_404_8@

任何人都知道如何找到根本原因,以及可能发生的事情？@H_404_8@

ethtool -K eth1 tx off rx off sg off tso off ufo off gso off gro off lro off rxvlan off txvlan off rxhash off