You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by zhenyuan wei <ti...@gmail.com> on 2018/08/23 09:09:56 UTC
How to trace one query？the debug/debugQuery info are not enough to find out why a query is slow
Hi all，
I do care query performance, but do not know how to find out the reason
why a query so slow.
*How to trace one query？*the debug/debugQuery info are not enough to find
out why a query is slow。
Thanks a lot~
Re: How to trace one query？the debug/debugQuery info are not enough to find out why a query is slow
Posted by Shawn Heisey <ap...@elyograg.org>.
On 8/24/2018 5:17 AM, zhenyuan wei wrote:
> Thanks again~ @Shawn @Jan Høydahl
> What is the recommend size of one shard？or how many docs per shard is
> recommend?
> My collection has 20 shard，each shard is 30~50GB。
There are no general rules. Every situation will be different, and
advice that works for one situation can be completely wrong for another.
If there is no other information available, we figure that if you're
going above 100 million docs per shard, that may be problematic. But
for some situations, it works fine. If your documents are only 300
bytes, you might not have any problem going above 100 million.
You cannot tell Solr "cache this field, but do not cache this other
field." The caches cannot be configured on a per-field basis like this.
The queryResultCache caches query results, if the result size is inside
the window size. The filterCache caches filter results. The
documentCache holds actual document contents, for the phase where Solr
is retrieving documents for search results.
Each entry in the filterCache tends to be large. If you have one
million documents in the shard, each filterCache entry for that shard
will be 125000 bytes -- one eighth of the document count.
> All I can do is resize filterCache，with 5 enumerate type，meybe 7.5GB x 5 =
> 37.5GB，
> and enable HDFS direcMemorySize as 20GB per node，using SSD for storage。
> As a result, if query cache is 2 times of 37.5GB, 75GB，
> I should use 11 solr node，each solr jvm node using 6GB RAM， and each node
> enable 10GB hdfs directMemorySize。
These cache sizes that you're mentioning are impossible on a machine
with only 32GB of memory, and definitely will not fit inside a heap size
of 6GB.
Your machines are not big enough for the index you're creating, and I
think you're probably going to need more machines.
Thanks,
Shawn
Re: How to trace one query？the debug/debugQuery info are not enough to find out why a query is slow
Posted by zhenyuan wei <ti...@gmail.com>.
Thanks again~ @Shawn @Jan Høydahl
What is the recommend size of one shard？or how many docs per shard is
recommend?
My collection has 20 shard，each shard is 30~50GB。
@Shawn according to your wiki and e-mail reply，
to achieve a better query performance ，I estimate the RAM requirement like
follow：
787GB 2billion docs，each document has 13 field。document field like follow：
*document { useid,phone,username,age,contry,city,province，job,
gender,height，weight，lastupdatetime，createTime }*
All fields will be search randomly，maybe combine with each other randomly
too.
So, in order to query fast, I should use
filterCache,queryResultCache,documentCache， and use HDFS directMemorySize.
Follow is the detail:
1. "userId" is document "id" field, no nead to cache.
2. "phone" is offen precise query，no nead to cache too
3. username maybe wildcard query，no nead to cache，due to cache is low hit
rate
4. age、contry、city、province、gender，these are enumerate type，we can cache
each type of them
age 0~100，filterCache maybe holds 100 object， total docId is 2billion，maybe
2billion * integer.size = 7.5GB
contry 190+， filterCache size mybe holds 190+ object，total docId is
2billion, 7.5GB
city，2billion docid , 7.5GB
province，2billion docid ,7.5GB
gender ， 2billion docid ,7.5GB
And those conditions maybe combine with each other while query happen，but
we can not enumerate them, and it is impossiable
to cache in all queryResultCache。
5. height、weight are double，and can not cache at all，and no rule to
estimate
6. lastupdatetime、createtime are long，always use range query，and no rule to
estimate
All I can do is resize filterCache，with 5 enumerate type，meybe 7.5GB x 5 =
37.5GB，
and enable HDFS direcMemorySize as 20GB per node，using SSD for storage。
As a result, if query cache is 2 times of 37.5GB, 75GB，
I should use 11 solr node，each solr jvm node using 6GB RAM， and each node
enable 10GB hdfs directMemorySize。
*Is there anything else to make it batter？*
Jan Høydahl <ja...@cominvent.com> 于2018年8月23日周四 下午9:38写道：
> Shawn, the block cache seems to be off-heap according to
> https://lucene.apache.org/solr/guide/7_4/running-solr-on-hdfs.html <
> https://lucene.apache.org/solr/guide/7_4/running-solr-on-hdfs.html>
>
> So you have 800G across 4 nodes, that gives 500M docs and 200G index data
> per solr node and 40G per shard.
> Initially I'd say this is way too much data and too little RAM per node
> but it obviously work due to the very small docs you have.
> So the first I'd try (after doing some analysis of various metrics for
> your running cluster) was to adjust the size of the hdfs block-cache
> following the instructions from the link above. You'll have 20-25Gb
> available for this, which is only 1/10 of the index size.
>
> So next step would be to replace the EC2 images with ones with more RAM
> and increase block cache further and see of that helps.
>
> Next I'd enable autoWarmCount on filterCache, find alternatives to
> wildcard query and more.
>
> But all in all, I'd be very very satisfied with those low response times
> given the size of your data.
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> > 23. aug. 2018 kl. 15:05 skrev Shawn Heisey <ap...@elyograg.org>:
> >
> > On 8/23/2018 5:19 AM, zhenyuan wei wrote:
> >> Thanks for your detail answer @Shawn
> >>
> >> Yes I run the query in SolrCloud mode, and my collection has 20 shards,
> >> each shard size is 30~50GB。
> >> 4 solr server, each solr JVM use 6GB, HDFS datanode are 4 too, each
> >> datanode JVM use 2.5GB。
> >> Linux server host are 4 node too，each node is 16 core/32GB RAM/1600GB
> SSD 。
> >>
> >> So, in order to search 2 billion docs fast( HDFS shows 787GB )，I should
> >> turn on autowarm，and How
> >> much solr RAM/how many solr node it should be？
> >> Is there a roughly formula to budget ？
> >
> > There are no generic answers, no rough formulas. Every install is
> different and minimum requirements are dependent on the specifics of the
> install.
> >
> > How many replicas do you have of each of those 20 shards? Is the 787GB
> of data the size of *one* replica, or the size of *all* replicas? Based on
> the info you shared, I suspect that it's the size of one replica.
> >
> > Here's a guide I've written:
> >
> > https://wiki.apache.org/solr/SolrPerformanceProblems
> >
> > That guide doesn't consider HDFS, so the info about the OS disk cache on
> that page is probably not helpful. I really have no idea what requirements
> HDFS has. I *think* that the HDFS client block cache would replace the OS
> disk cache, and that the Solr heap must be increased to accommodate that
> block cache. This might lead to GC issues, though, because ideally the
> cache would be large enough to cache all of the index data that the Solr
> instance is accessing. In your case, that's a LOT of data, far more than
> you can fit into the 32GB total system memory.Solr performance will suffer
> if you're not able to have the system cache Solr's index data. But I will
> tell you that achieving a QTime of 125 on a wildcard query against a 2
> billion document index is impressive, not something I would expect to
> happen with the low hardware resources you're using.
> >
> > You have 20 shards. If your replicationFactor is 3, then ideally you
> would have 60 servers - one for each shard replica. Each server would have
> enough memory installed that it could cache the 30-50GB of data in that
> shard, or at least MOST of it.
> >
> > IMHO, Solr should be using local storage, not a network filesystem like
> HDFS. Things are a lot more straightforward that way.
> >
> > Thanks,
> > Shawn
> >
>
>
Re: How to trace one query？the debug/debugQuery info are not enough to find out why a query is slow
Posted by Jan Høydahl <ja...@cominvent.com>.
Shawn, the block cache seems to be off-heap according to https://lucene.apache.org/solr/guide/7_4/running-solr-on-hdfs.html <https://lucene.apache.org/solr/guide/7_4/running-solr-on-hdfs.html>
So you have 800G across 4 nodes, that gives 500M docs and 200G index data per solr node and 40G per shard.
Initially I'd say this is way too much data and too little RAM per node but it obviously work due to the very small docs you have.
So the first I'd try (after doing some analysis of various metrics for your running cluster) was to adjust the size of the hdfs block-cache following the instructions from the link above. You'll have 20-25Gb available for this, which is only 1/10 of the index size.
So next step would be to replace the EC2 images with ones with more RAM and increase block cache further and see of that helps.
Next I'd enable autoWarmCount on filterCache, find alternatives to wildcard query and more.
But all in all, I'd be very very satisfied with those low response times given the size of your data.
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
> 23. aug. 2018 kl. 15:05 skrev Shawn Heisey <ap...@elyograg.org>:
>
> On 8/23/2018 5:19 AM, zhenyuan wei wrote:
>> Thanks for your detail answer @Shawn
>>
>> Yes I run the query in SolrCloud mode, and my collection has 20 shards,
>> each shard size is 30~50GB。
>> 4 solr server, each solr JVM use 6GB, HDFS datanode are 4 too, each
>> datanode JVM use 2.5GB。
>> Linux server host are 4 node too，each node is 16 core/32GB RAM/1600GB SSD 。
>>
>> So, in order to search 2 billion docs fast( HDFS shows 787GB )，I should
>> turn on autowarm，and How
>> much solr RAM/how many solr node it should be？
>> Is there a roughly formula to budget ？
>
> There are no generic answers, no rough formulas. Every install is different and minimum requirements are dependent on the specifics of the install.
>
> How many replicas do you have of each of those 20 shards? Is the 787GB of data the size of *one* replica, or the size of *all* replicas? Based on the info you shared, I suspect that it's the size of one replica.
>
> Here's a guide I've written:
>
> https://wiki.apache.org/solr/SolrPerformanceProblems
>
> That guide doesn't consider HDFS, so the info about the OS disk cache on that page is probably not helpful. I really have no idea what requirements HDFS has. I *think* that the HDFS client block cache would replace the OS disk cache, and that the Solr heap must be increased to accommodate that block cache. This might lead to GC issues, though, because ideally the cache would be large enough to cache all of the index data that the Solr instance is accessing. In your case, that's a LOT of data, far more than you can fit into the 32GB total system memory.Solr performance will suffer if you're not able to have the system cache Solr's index data. But I will tell you that achieving a QTime of 125 on a wildcard query against a 2 billion document index is impressive, not something I would expect to happen with the low hardware resources you're using.
>
> You have 20 shards. If your replicationFactor is 3, then ideally you would have 60 servers - one for each shard replica. Each server would have enough memory installed that it could cache the 30-50GB of data in that shard, or at least MOST of it.
>
> IMHO, Solr should be using local storage, not a network filesystem like HDFS. Things are a lot more straightforward that way.
>
> Thanks,
> Shawn
>
Re: How to trace one query？the debug/debugQuery info are not enough to find out why a query is slow
Posted by Shawn Heisey <ap...@elyograg.org>.
On 8/23/2018 5:19 AM, zhenyuan wei wrote:
> Thanks for your detail answer @Shawn
>
> Yes I run the query in SolrCloud mode, and my collection has 20 shards,
> each shard size is 30~50GB。
> 4 solr server, each solr JVM use 6GB, HDFS datanode are 4 too, each
> datanode JVM use 2.5GB。
> Linux server host are 4 node too，each node is 16 core/32GB RAM/1600GB SSD 。
>
> So, in order to search 2 billion docs fast( HDFS shows 787GB )，I should
> turn on autowarm，and How
> much solr RAM/how many solr node it should be？
> Is there a roughly formula to budget ？
There are no generic answers, no rough formulas. Every install is
different and minimum requirements are dependent on the specifics of the
install.
How many replicas do you have of each of those 20 shards? Is the 787GB
of data the size of *one* replica, or the size of *all* replicas? Based
on the info you shared, I suspect that it's the size of one replica.
Here's a guide I've written:
https://wiki.apache.org/solr/SolrPerformanceProblems
That guide doesn't consider HDFS, so the info about the OS disk cache on
that page is probably not helpful. I really have no idea what
requirements HDFS has. I *think* that the HDFS client block cache would
replace the OS disk cache, and that the Solr heap must be increased to
accommodate that block cache. This might lead to GC issues, though,
because ideally the cache would be large enough to cache all of the
index data that the Solr instance is accessing. In your case, that's a
LOT of data, far more than you can fit into the 32GB total system
memory.Solr performance will suffer if you're not able to have the
system cache Solr's index data. But I will tell you that achieving a
QTime of 125 on a wildcard query against a 2 billion document index is
impressive, not something I would expect to happen with the low hardware
resources you're using.
You have 20 shards. If your replicationFactor is 3, then ideally you
would have 60 servers - one for each shard replica. Each server would
have enough memory installed that it could cache the 30-50GB of data in
that shard, or at least MOST of it.
IMHO, Solr should be using local storage, not a network filesystem like
HDFS. Things are a lot more straightforward that way.
Thanks,
Shawn
Re: How to trace one query？the debug/debugQuery info are not enough to find out why a query is slow
Posted by zhenyuan wei <ti...@gmail.com>.
Thanks for your detail answer @Shawn
Yes I run the query in SolrCloud mode, and my collection has 20 shards,
each shard size is 30~50GB。
4 solr server, each solr JVM use 6GB, HDFS datanode are 4 too, each
datanode JVM use 2.5GB。
Linux server host are 4 node too，each node is 16 core/32GB RAM/1600GB SSD 。
So, in order to search 2 billion docs fast( HDFS shows 787GB )，I should
turn on autowarm，and How
much solr RAM/how many solr node it should be？
Is there a roughly formula to budget ？
Thanks again ~
TinsWzy
Shawn Heisey <ap...@elyograg.org> 于2018年8月23日周四 下午6:19写道：
> On 8/23/2018 4:03 AM, Shawn Heisey wrote:
> > Configuring caches cannot speed up the first time a query runs. That
> > speeds up later runs. To speed up the first time will require two
> > things:
> >
> > 1) Ensuring that there is enough memory in the system for the
> > operating system to effectively cache the index. This is memory
> > *beyond* the java heap that is not allocated to any program.
>
> Followup, after fully digesting the latest reply:
>
> HDFS changes things a little bit. You would need to talk to somebody
> about caching HDFS data effectively. I think that in that case, you
> *do* need to use the heap to create a large HDFS client cache, but I
> have no personal experience with HDFS, so I do not know for sure. Note
> that having a very large heap can make garbage collection pauses become
> extreme.
>
> With 2 billion docs, I'm assuming that you're running SolrCloud and that
> the index is sharded. SolrCloud gives you query load balancing for
> free. But I think you're probably going to need a lot more than 4
> servers, and each server is probably going to need a lot of memory. You
> haven't indicated how many shards or replicas are involved here. For
> optimal performance, every shard needs to be on a separate server.
>
> Searching 2 billion docs, especially with wildcards, may not be possible
> to get working REALLY fast. Without a LOT of hardware, particularly
> memory, it can be completely impractical to cache that much data.
> Terabytes of memory is *very* expensive, especially if it's scattered
> across many servers.
>
> Thanks,
> Shawn
>
>
Re: How to trace one query？the debug/debugQuery info are not enough to find out why a query is slow
Posted by Shawn Heisey <ap...@elyograg.org>.
On 8/23/2018 4:03 AM, Shawn Heisey wrote:
> Configuring caches cannot speed up the first time a query runs. That
> speeds up later runs. To speed up the first time will require two
> things:
>
> 1) Ensuring that there is enough memory in the system for the
> operating system to effectively cache the index. This is memory
> *beyond* the java heap that is not allocated to any program.
Followup, after fully digesting the latest reply:
HDFS changes things a little bit. You would need to talk to somebody
about caching HDFS data effectively. I think that in that case, you
*do* need to use the heap to create a large HDFS client cache, but I
have no personal experience with HDFS, so I do not know for sure. Note
that having a very large heap can make garbage collection pauses become
extreme.
With 2 billion docs, I'm assuming that you're running SolrCloud and that
the index is sharded. SolrCloud gives you query load balancing for
free. But I think you're probably going to need a lot more than 4
servers, and each server is probably going to need a lot of memory. You
haven't indicated how many shards or replicas are involved here. For
optimal performance, every shard needs to be on a separate server.
Searching 2 billion docs, especially with wildcards, may not be possible
to get working REALLY fast. Without a LOT of hardware, particularly
memory, it can be completely impractical to cache that much data.
Terabytes of memory is *very* expensive, especially if it's scattered
across many servers.
Thanks,
Shawn
Re: How to trace one query？the debug/debugQuery info are not enough to find out why a query is slow
Posted by Shawn Heisey <ap...@elyograg.org>.
On 8/23/2018 3:41 AM, zhenyuan wei wrote:
> Thank you very much to answer. @Jan Høydahl
> My query is simple, just wildcard last 2 char in this query（have more other
> query to optimize）
>
> curl "
> http://emr-worker-1:8983/solr/collection005/query?q=v10_s:OOOOOOOOVVVVVVVVYY*&rows=10&&fl=id&echoParams=all
> "
I think that's the answer right there -- wildcard query. Wildcard
queries have a tendency to be slow, because of how they work. What is
the nature of your v10_s field? Does that wildcard query match a lot of
terms? When a wildcard query executes, Solr asks the index for all
terms that match it, and then constructs a query with all of those terms
in it. If there are ten million terms that match the wildcard, the
query will *quite literally* have ten million entries inside it. Every
one of the terms will need to be separately searched against the index.
Each term will be fast, but it adds up if there are a lot of them. This
query had a numFound larger than one hundred thousand. Which suggests
that there were at least that many terms in the query. So basically in
the time it took, Solr first gathered a huge list of terms, and then
internally executed over one hundred thousand individual queries.
Changing your field definition so you can avoid wildcard queries will go
a long way towards speeding things up.Typically this involves some kind
of ngram tokenizer or filter. It will make the index much larger, but
tends to speed things up.
Your example says the QTime is 125 milliseconds, and your message talks
about times of 40 milliseconds. This is NOT slow. If you're trying to
maximize queries per second, you need to know that handling a high query
load requires multiple servers handling multiple replicas of your index,
and some kind of load balancing.
Configuring caches cannot speed up the first time a query runs. That
speeds up later runs. To speed up the first time will require two things:
1) Ensuring that there is enough memory in the system for the operating
system to effectively cache the index. This is memory *beyond* the java
heap that is not allocated to any program.
2) Changing the query to a type that executes faster and adjusting the
schema to allow the new type to work. Wildcard queries are one of the
worst options.
In a later message, you indicated that your cache autowarmCount values
are mostly set to zero. This means that anytime you make a change to
the index, your caches are completely gone, and that the one cache with
a nonzero setting is using NoOpRegenerator, so it's not actually doing
any warming. With auto warming, the most recent entries in the cache
will be re-executed to warm the new caches. This can help with
performance, but if you make autoWarmCount too large, it will make
commits take a very long time. Note that documentCache actually doesn't
do warming, so that setting is irrelevant on that cache.
Thanks,
Shawn
Re: How to trace one query？the debug/debugQuery info are not enough to find out why a query is slow
Posted by zhenyuan wei <ti...@gmail.com>.
I have 4 solr server, each allocated 6GB。My dataset on HDFS is 787GB, 2 billion
documents totally，each document is 300 Bytes。 Follow is my cache related
configuration。
<filterCache class="solr.FastLRUCache"
size="512"
initialSize="512"
autowarmCount="0"/>
<queryResultCache class="solr.LRUCache"
size="512"
initialSize="512"
autowarmCount="0"/>
<documentCache class="solr.LRUCache"
size="512"
initialSize="512"
autowarmCount="0"/>
<cache name="perSegFilter"
class="solr.search.LRUCache"
size="10"
initialSize="0"
autowarmCount="10"
regenerator="solr.NoOpRegenerator" />
<queryResultWindowSize>20</queryResultWindowSize>
<queryResultMaxDocsCached>200</queryResultMaxDocsCached>
zhenyuan wei <ti...@gmail.com> 于2018年8月23日周四 下午5:41写道：
> Thank you very much to answer. @Jan Høydahl
> My query is simple, just wildcard last 2 char in this query（have more
> other query to optimize）
>
> curl "
> http://emr-worker-1:8983/solr/collection005/query?q=v10_s:OOOOOOOOVVVVVVVVYY*&rows=10&&fl=id&echoParams=all
> "
> {
> "responseHeader":{
> "zkConnected":true,
> "status":0,
> "*QTime":125,*
> "params":{
> "q":"v10_s:OOOOOOOOVVVVVVVVYY*",
> "df":"_text_",
> "echoParams":"all",
> "indent":"true",
> "fl":"id",
> "rows":"10",
> "wt":"json"}},
> "response":{"numFound":118181,"start":0,"maxScore":1.0,"docs":[
> .......
> }}
>
> The first time query , it return slow, second time it returns very fast。It
> maybe cached already。
> With "debugQuery=true&shards.info=true", I can see all shards toke 40
> or more millisecond 。
> The second time the query executes ， all shards query spend only 1~5
> millisecond。
> But I dont know how to optimize the first time the query
> execute，filterCache?QueryResultCache?
> or hdfs blockCache? and how much RAM I should allocate to them？
>
> I want to turn down QTime to 50ms or less in the first time query executes。
>
>
>
>
> Jan Høydahl <ja...@cominvent.com> 于2018年8月23日周四 下午5:19写道：
>
>> Hi,
>>
>> With debugQuery you see the timings. What component spends the most time?
>> With shards.info=true you see what shard is the slowest, if your index
>> is sharded.
>> With echoParams=all you get the full list of query parameters in use,
>> perhaps you spot something?
>> If you start Solr with -v option then you get more verbose logging in
>> solr.log which may help
>>
>> Can you share with us how your query looks like, including all parameters
>> from the <params> section with echoParams=all enabled?
>>
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>>
>> > 23. aug. 2018 kl. 11:09 skrev zhenyuan wei <ti...@gmail.com>:
>> >
>> > Hi all，
>> > I do care query performance, but do not know how to find out the
>> reason
>> > why a query so slow.
>> > *How to trace one query？*the debug/debugQuery info are not enough to
>> find
>> > out why a query is slow。
>> >
>> >
>> > Thanks a lot~
>>
>>
Re: How to trace one query？the debug/debugQuery info are not enough to find out why a query is slow
Posted by zhenyuan wei <ti...@gmail.com>.
Thank you very much to answer. @Jan Høydahl
My query is simple, just wildcard last 2 char in this query（have more other
query to optimize）
curl "
http://emr-worker-1:8983/solr/collection005/query?q=v10_s:OOOOOOOOVVVVVVVVYY*&rows=10&&fl=id&echoParams=all
"
{
"responseHeader":{
"zkConnected":true,
"status":0,
"*QTime":125,*
"params":{
"q":"v10_s:OOOOOOOOVVVVVVVVYY*",
"df":"_text_",
"echoParams":"all",
"indent":"true",
"fl":"id",
"rows":"10",
"wt":"json"}},
"response":{"numFound":118181,"start":0,"maxScore":1.0,"docs":[
.......
}}
The first time query , it return slow, second time it returns very fast。It
maybe cached already。
With "debugQuery=true&shards.info=true", I can see all shards toke 40 or
more millisecond 。
The second time the query executes ， all shards query spend only 1~5
millisecond。
But I dont know how to optimize the first time the query
execute，filterCache?QueryResultCache?
or hdfs blockCache? and how much RAM I should allocate to them？
I want to turn down QTime to 50ms or less in the first time query executes。
Jan Høydahl <ja...@cominvent.com> 于2018年8月23日周四 下午5:19写道：
> Hi,
>
> With debugQuery you see the timings. What component spends the most time?
> With shards.info=true you see what shard is the slowest, if your index is
> sharded.
> With echoParams=all you get the full list of query parameters in use,
> perhaps you spot something?
> If you start Solr with -v option then you get more verbose logging in
> solr.log which may help
>
> Can you share with us how your query looks like, including all parameters
> from the <params> section with echoParams=all enabled?
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> > 23. aug. 2018 kl. 11:09 skrev zhenyuan wei <ti...@gmail.com>:
> >
> > Hi all，
> > I do care query performance, but do not know how to find out the
> reason
> > why a query so slow.
> > *How to trace one query？*the debug/debugQuery info are not enough to find
> > out why a query is slow。
> >
> >
> > Thanks a lot~
>
>
Re: How to trace one query？the debug/debugQuery info are not enough to find out why a query is slow
Posted by Jan Høydahl <ja...@cominvent.com>.
Hi,
With debugQuery you see the timings. What component spends the most time?
With shards.info=true you see what shard is the slowest, if your index is sharded.
With echoParams=all you get the full list of query parameters in use, perhaps you spot something?
If you start Solr with -v option then you get more verbose logging in solr.log which may help
Can you share with us how your query looks like, including all parameters from the <params> section with echoParams=all enabled?
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
> 23. aug. 2018 kl. 11:09 skrev zhenyuan wei <ti...@gmail.com>:
>
> Hi all，
> I do care query performance, but do not know how to find out the reason
> why a query so slow.
> *How to trace one query？*the debug/debugQuery info are not enough to find
> out why a query is slow。
>
>
> Thanks a lot~