Thanks, Michael.
I missed that mail thread among all responses. I will check that too.
On Thu, May 5, 2022 at 6:26 PM Michael Gibney
wrote:
> Did you yet dig through the mailing list thread link that I posted earlier
> in this thread? It explains in more depth, suggests a number of possible
>
Did you yet dig through the mailing list thread link that I posted earlier
in this thread? It explains in more depth, suggests a number of possible
mitigations, and has a bunch of links to jira issues that provide extra
context. Off the cuff, I'd say that setting `enableGraphQueries=false` may
be m
Hi Michael,
1. set `pf=` (phrase field empty string), disabling implicit phrase query
> building. This would help give a sense of whether phrase queries are
> involved in the performance issues you're seeing.
We are also in the process of moving from standalone 6.6 to 8.7 Solr cloud,
We also no
Hi,
I tried with separate volumes on each instance and the results are still
slow. The addition of more rows in the search query causes the search time
to increase by multiple folds.
The QTime and Elapsed time are both increased for request GET_TOP_GROUPS.
Following is the group field definition.
Thanks Walter for your reply. Yes it is the same disk shared on all
instances.
Thanks,
Modassar
On Fri, Apr 8, 2022 at 10:54 AM Walter Underwood
wrote:
> Are you sharing the same disk volume on all instances? I would expect that
> to be slow and cause index corruption. Each instance should have
Are you sharing the same disk volume on all instances? I would expect that to
be slow and cause index corruption. Each instance should have its own disk
volumes. I’m looking at this part of your config.
Storage : Multi-attach EBS Volume. Provisioned IOPS SSD (io1) with 3000 IOPS.
wunder
Walter
Hi,
I tried a few different settings of GC and observed the following. The best
result I got with the following environment and GC settings but still it is
comparatively slower than the previous Solr-6.5.1 setup.
Total index : 4+ TB
Servers : 3 instances of x2gd.4xlarge systems each having 16 CPU
On 3/27/2022 1:20 PM, Modassar Ather wrote:
Just to add one point, even the queries without the wildcards e.g. a
boolean query or a query with 1 ids ORed has also become slow and it is
also taking more CPU and finally ending up taking more time.
I understand this is due to many GC pauses so i
Thanks for your replies.
Yes, adding more physical memory will help but in the current situation
even the GC settings which we have used may not be the optimal one. Can you
please provide some suggestions on GC settings?
We are also planning to add more shards and create smaller indexes per
shard
I agree with Shawn about ideally wanting more memory for the OS.
That said, the WordDelimiterFilter config you sent aligns with my suspicion
that "graph phrase" issues are likely to explain the difference between 6.5
and 8.11. At query-time, WordDelimiterFilter (and also equally
WordDelimiterGraph
On 3/27/2022 5:30 AM, Modassar Ather wrote:
The wildcard queries are executed against the text data and yes there are a
huge number of possible expansions of the wildcard query.
All the 12 shards are on a single machine with 521 GB memory and each shard
is started with SOLR_JAVA_MEM="-Xmx30g". So
Thank you all for the suggestions.
I will try to profile and find the bottleneck.
I am getting the following exception which I understand may be due to the
multiterm field expansion for the wildcard query. Please correct me if I am
wrong.
*The request took too long to iterate over doc values.*
T
On 3/26/2022 6:24 AM, Mike Drob wrote:
Can you provide more details on what they CPU time is spent on? Maybe look
at some JFR profiles or collect several jstacks to see where they
bottlenecks are.
On Sat, Mar 26, 2022 at 3:49 AM Modassar Ather
wrote:
We are trying to migrate to Solr-8.11.0 fr
Are you using query-time multi-term synonyms or WordDelimiter[Graph]Filter?
-- these can trigger "graph phrase" queries, which are handled _quite_
differently in Solr 8.11 vs 6.5 (and although unlikely to directly cause
the performance issues you're observing, might well explain the performance
dis
Can you provide more details on what they CPU time is spent on? Maybe look
at some JFR profiles or collect several jstacks to see where they
bottlenecks are.
On Sat, Mar 26, 2022 at 3:49 AM Modassar Ather
wrote:
> Hi,
>
> We are trying to migrate to Solr-8.11.0 from Solr-6.5.1. Following are the
15 matches
Mail list logo
