On 5/10/2019 7:32 AM, vishal patel wrote:
We have 2 shards and 2 replicas in Live environment. we have multiple
collections.
Some times some query takes much time(QTime=52552). There are so many
documents indexing and searching within milliseconds.
There could be any number of causes of slow performance.
A common reason is not having enough spare memory in the machine to
allow the operating system to cache the index data. This is memory NOT
allocated by programs (including Solr).
Another common reason is that the heap size is too small, which causes
Java to frequently perform full garbage collections, which will REALLY
kill performance.
Since there's very little information here, it's difficult for us to
diagnose the cause. Here's a wiki page about performance problems:
https://wiki.apache.org/solr/SolrPerformanceProblems
(Disclaimer: I am the principal author of that page)
When we executed the same query again using admin panel, it does not take a
much time and it completes within 20 milliseconds.
Executing an identical query again will likely satisfy the query from
Solr's caches. Solr won't need to talk to the actual index, and it will
be REALLY fast. Even a massively complex query, if it is cached, will
be fast.
Running the information from your logs through a URL decoder, this is
what I found:
q=+project_id:(2102117)+recipient_id:(4642365) +entity_type:(1)
-action_id:(20 32) +action_status:(0) +is_active:(true)
+(is_formtype_active:true) +(appType:1)
If all of those fields are indexed, then I would not expect a properly
sized server to be slow. If any of those fields are indexed=false and
have docValues, then it could be a schema configuration issue.
Searching docValues does work, but it's really slow.
Your query does have an empty fq ... "fq=" ... I do not know whether
that's problematic. Try it without that to verify. I would not expect
it to cause problems, but I can't be sure.
Thanks,
Shawn
