That sounds like it. Sorry my memory is so hazy. Maybe Yonik can either confirm that that Jira is still outstanding or close it, and confirm if these symptoms are related.
-- Jack Krupansky On Thu, Jan 14, 2016 at 10:54 AM, Erick Erickson <erickerick...@gmail.com> wrote: > Jack: > > I think that was for faceting? SOLR-8096 maybe? > > > On Thu, Jan 14, 2016 at 12:25 AM, Toke Eskildsen <t...@statsbiblioteket.dk> > wrote: > > On Wed, 2016-01-13 at 15:01 -0700, Anria B. wrote: > > > > [256GB RAM] > > > >> 1. Collection has 20-30 million docs. > > > > Just for completeness: How large is the collection in bytes? > > > >> 2. q=*&fq=someField:SomeVal ---> takes 2.5 seconds > >> 3. q=someField:SomeVal --> 300ms > >> 4. as numFound -> infinity, qtime -> infinity. > > > > What are you doing besides the q + fq above? Assuming a modest size > > index (let's say < 100GB), even 300ms for a simple key:value query is a > > long time. Usual culprits for performance problems when result set size > > grows are high values for rows, grouping and faceting. > > > > Could you experiment with > > q=queryA&fq=queryB > > vs > > q=queryA AND queryB > > to make sure that is is not the underlying queries themselves that > > causes the slowdown? > > > > Also, could you check the speed of the first request for > > q=queryA&fq=queryB > > vs subsequent requests (you might need to set the queryResultCache to > > zero to force a re-calculation of the result set), to see whether is is > > the creation of the fq result set or the intersection calculation that > > is slow? > > > >> We have already tested different autoCommit strategies, and different > values > >> for heap size, starting at 16GB, 32GB, 64GB, 128GB ... The only > place we > >> saw a 100ms improvement was between 32 - -Xmx=64GB. > > > > I would guess the 100 ms improvement was due to a factor not related to > > heap size. With the exception of a situation where the heap is nearly > > full, increasing Xmx will not improve Solr performance significantly. > > > > Quick note: Never set Xmx in the range 32GB-40GB (40GB is approximate): > > At the 32GB point, the JVM switches to larger pointers, which means that > > effective heap space is _smaller_ for Xmx=33GB than it is for Xmx=31GB: > > > https://blog.codecentric.de/en/2014/02/35gb-heap-less-32gb-java-jvm-memory-oddities/ > > > > - Toke Eskildsen, State and University Library, Denmark > > > > >
