Re: Zk big files issues and model store

Hello, I've created an issue and a PR ( https://issues.apache.org/jira/browse/SOLR-17050) The models will also be smaller because they will be saved without newlines and without spaces after keys: > ~ cat d.txt > "x":{"y":{"z":{"foobar":42}}} > ~ wc -c d.txt > 30 d.txt For example the fol

Re: Zk big files issues and model store

Thanks for the suggestion Matthias. I will look into this. Hello Christine. One of the concerns is the split nature but also that if the file does not exist on disk when the replica reloads, the core would not load. To keep the models in sync on each node can be quite complicated. For example you

Zk big files issues and model store

? Could this work and allow us to postpone the moment of using DefaultWrapperModel? Thanks, Florin Babes

Re: Exception thrown during intensive batch partial updating and segment merging

Hello, I've created an issue https://issues.apache.org/jira/browse/SOLR-15420. If I find anymore info about this I will post there. Thanks, Florin Babes În lun., 10 mai 2021 la 17:44, Florin Babes a scris: > Hello, > I have the following situation: > solr 8.8.2 standalone > cor

Exception thrown during intensive batch partial updating and segment merging

Hello, I have the following situation: solr 8.8.2 standalone core with ~7 million documents Daily we run an import in which we update all 7 million documents. The updated field is a multifield that can contain up to 300 string (max 5 words). Updating so many documents triggers a segment merge in w

Re: Frequent OutOfMemoryError on production solr

184 > -XX:MarkStackSize=4194304 -XX:MaxHeapSize=17179869184 > -XX:MaxNewSize=10301210624 -XX:MinHeapDeltaBytes=8388608 > -XX:NumberOfGCLogFiles=9 -XX:+PrintGC -XX:+PrintGCApplicationStoppedTime > -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps > -XX:+PrintHeapAtGC -XX:+Pr

Re: Frequent OutOfMemoryError on production solr

Hello, Can you give a query example, cache configuration, JVM gc configuration and heap size, grouping field cardinality? Thanks, Florin Babeş În joi, 25 mar. 2021 la 10:16, Parshant Kumar a scris: > Yes we are using grouped queries > > On Thu, Mar 25, 2021, 1:42 PM Saurabh Sharma > wrote: >

Re: Increase in response time in case of collapse queries.

is an interesting finding. The default behavior is quite fast compared > to the sort approach. > > > > Joel Bernstein > http://joelsolr.blogspot.com/ > > > On Wed, Mar 17, 2021 at 3:42 AM Florin Babes > wrote: > > > @Gajendra we used a sort="score de

Re: Increase in response time in case of collapse queries.

>> > >> > >> > >> > >> > >> > >> > >> > >> Joel Bernstein > >> http://joelsolr.blogspot.com/ > >> > >> > >> On Mon, Mar 8, 2021 at 11:30 AM Gajendra Dadheech > >> wrote:

Re: Increase in response time in case of collapse queries.

t; > On Mon, Mar 8, 2021 at 4:41 PM Florin Babes wrote: > > > We improved the performance of collapse by making the group_field null > for > > the documents that have an unique value for group_field. This might help/ > > > > > > În lun., 8 mar. 2021 la

Re: Increase in response time in case of collapse queries.

umar > > On Mon, Mar 8, 2021 at 4:06 PM Florin Babes wrote: > > > Your group_field has a high cardinality? > > Thanks, > > Florin Babes > > > > În lun., 8 mar. 2021 la 10:35, Parshant Kumar > > a scris: > > > > > Hi florin, > > &g

Re: Increase in response time in case of collapse queries.

Your group_field has a high cardinality? Thanks, Florin Babes În lun., 8 mar. 2021 la 10:35, Parshant Kumar a scris: > Hi florin, > > I am using below. > > 1) fq={!collapse field=parentglusrid} > 2) expand.rows=4 > 3) expand=true > > Size of index is around 100GB. &

Re: Increase in response time in case of collapse queries.

c) and the head selecting will be faster. What is your head selecting strategy? Can you share your fq which you use for collapsing? Thanks, Florin Babes În lun., 8 mar. 2021 la 06:44, Parshant Kumar a scris: > anyone please help > > On Wed, Mar 3, 2021 at 4:55 PM Parshant Ku