Re: slow performance on phrase queries in should clause

McCandless > > http://blog.mikemccandless.com > > 2014-12-04 19:21 GMT-05:00 Kireet Reddy >: > >> Our system is normally very responsive, but very occasionally people >> submit long phrase queries which timeout and cause high system load. Not >> all long phrase

slow performance on phrase queries in should clause

Our system is normally very responsive, but very occasionally people submit long phrase queries which timeout and cause high system load. Not all long phrase queries cause issues, but I have been debugging one that I've found.[1] The query is in the filter section of a constant score query as b

slow execution of nested boolean filter

I have a query with a nested boolean (boolean within a boolean) filter with a should clause that performs really terribly. But if I move the nested query up to top level, it performs as much as 50x faster. I am struggling to understand why this is the case. Here are the 2 forms: https://gist.g

Re: slow filter execution

et to true. Not sure if this has been fixed in 1.3.x yet or not. This meshes with my observed behavior. On Wednesday, July 30, 2014 8:59:37 AM UTC-7, Kireet Reddy wrote: > > Thanks for the detailed reply. > > I am a bit confused about and vs bool filter execution. I read t

Re: slow filter execution

Thanks for the detailed reply. I am a bit confused about and vs bool filter execution. I read this post on the elasticsearch blog. From that, I thought the bool filter would work by basically creating a bitset for the

Re: slow filter execution

@scrutmydocs > > > Le 30 juil. 2014 à 05:03, Kireet Reddy a écrit : > > One of my queries has been consistently taking 500ms-1s and I can't figure > out why. Here is the query > <https://gist.github.com/anonymous/d98fb2c46d9a7755e882> (it looks a bit > strange as I h

slow filter execution

One of my queries has been consistently taking 500ms-1s and I can't figure out why. Here is the query (it looks a bit strange as I have removed things that didn't seem to affect execution time). When I remove the range filter, the query c

Re: Constant High (~99%) CPU on 1 of 5 Nodes in Cluster

We've had a very similar issue, but haven't been able to figure out what the problem is. How do you "fix" the problem? Will a node restart fix the problem immediately or do you need to restart the whole machine? On Tuesday, July 29, 2014 1:59:52 PM UTC-7, mic...@modernmast.com wrote: > > Hey gu

Re: Use java Api to set a document's field as _id

You should check out the IndexRequestBuilder class. It helps simplify creating indexing requests and has a setId() method. On Friday, July 25, 2014 4:22:42 PM UTC-7, Chia-Eng Chang wrote: > > I want to ask if the unique field _id be assigned by certain field within > document. I see with Rest, i

Re: Clustering/Sharding impact on query performance

; cluster with a lot of machines. I could observe this negative effects while > testing with 20 shards. > > It would be very cool if somebody could answer/comment to the question > summarized at the end of my post. Thanks again. > > > > > > On Friday, July 11, 2

Re: excessive merging/small segment sizes

there. On Sunday, July 13, 2014 2:33:00 AM UTC-7, Michael McCandless wrote: > > On Fri, Jul 11, 2014 at 7:35 PM, Kireet Reddy > wrote: > >> The problem reappeared. We did some tests today around copying a large >> file on the nodes to test i/o throughput. On the loaded node,

Re: Frequent OOM

Does it seem related to search activity? Merge activity? What does the hot threads endpoint show before running out of memory? I might try to cap the max segment size or use more shards so the segments stay less than the heap size (maybe target 2GB?) On Wednesday, July 9, 2014 5:00:29 AM UTC-7,

Re: Clustering/Sharding impact on query performance

I would test using multiple primary shards on a single machine. Since your dataset seems to fit into RAM, this could help for these longer latency queries. On Thursday, July 10, 2014 12:24:26 AM UTC-7, Fin Sekun wrote: > > Any hints? > > > > On Monday, July 7, 2014 3:51:19 PM UTC+2, Fin Sekun wr

Re: excessive merging/small segment sizes

Sorry, forgot the link https://www.dropbox.com/sh/3s6m0bhz4eshi6m/AAD8g3Ukq1UW0IbPV-a-CrBGa/1229.txt On Wednesday, July 9, 2014 1:05:56 PM UTC-7, Kireet Reddy wrote: > > The problem is happening again, this time on node 5. I have captured a few > hot thread requests here. I also inc

Re: excessive merging/small segment sizes

og. > > Are there any scheduled jobs, e.g. backups/snapshots, that start up? Are > you running on virtualized hardware? > > > Mike McCandless > > http://blog.mikemccandless.com > > > On Sun, Jul 6, 2014 at 8:23 PM, Kireet Reddy > wrote: > >> Just to

Re: excessive merging/small segment sizes

Just to reiterate, the problematic period is from 07/05 14:45 to 07/06 02:10. I included a couple hours before and after in the logs. On Sunday, July 6, 2014 5:17:06 PM UTC-7, Kireet Reddy wrote: > > They are linked below (node5 is the log of the normal node, node6 is the > l

Re: excessive merging/small segment sizes

to think that the docs that land on this node are "different" in > any way? > > Mike McCandless > > http://blog.mikemccandless.com > > > On Sun, Jul 6, 2014 at 6:48 PM, Kireet Reddy > wrote: > >> From all the information I’ve collected, it seems t

excessive merging/small segment sizes

We have a situation where one of the four nodes in our cluster seems to get caught up endlessly merging. However it seems to be high CPU activity and not I/O constrainted. I have enabled the IndexWriter info stream logs, and often times it seems to do merges of quite small segments (100KB) that

Re: node failures

; it's very resource intensive though but it if reduces your segment count > then it may allude to where the problem lies. > > Regards, > Mark Walkom > > Infrastructure Engineer > Campaign Monitor > email: ma...@campaignmonitor.com > web: www.campaignmonitor.com >

Re: node failures

Mark Walkom > > Infrastructure Engineer > Campaign Monitor > email: ma...@campaignmonitor.com > web: www.campaignmonitor.com > > > On 11 June 2014 00:41, Kireet Reddy wrote: > On our 4 node test cluster (1.1.2), seemingly out of the blue we had one node > experience very

node failures

On our 4 node test cluster (1.1.2), seemingly out of the blue we had one node experience very high cpu usage and become unresponsive and then after about 8 hours another node experienced the same issue. The processes themselves stayed alive, gc activity was normal, they didn't experience an Out