On 9/4/15, 7:06 AM, "Yonik Seeley" wrote:
>
>Lucene seems to always be changing it's execution model, so it can be
>difficult to keep up. What version of Solr are you using?
>Lucene also changed how filters work, so now, a filter is
>incorporated with the query like so:
>
>query = new BooleanQ
>> This is part of a bigger issue we should work at doing better at for
>> Solr 6: debugability / supportability.
>> For a specific request, what took up the memory, what cache misses or
>> cache instantiations were there, how much request-specific memory was
>> allocated, how much shared memory wa
Yes please.:
http://www.amazon.com/Solr-Troubleshooting-Maintenance-Alexandre-Rafalovitch/dp/1491920149/
:-)
Regards,
Alex.
Solr Analyzers, Tokenizers, Filters, URPs and even a newsletter:
http://www.solr-start.com/
On 4 September 2015 at 10:30, Yonik Seeley wrote:
> On Fri, Sep 4,
On Fri, Sep 4, 2015 at 10:18 AM, Alexandre Rafalovitch
wrote:
> Yonik,
>
> Is this all visible on query debug level?
Nope, unfortunately not.
This is part of a bigger issue we should work at doing better at for
Solr 6: debugability / supportability.
For a specific request, what took up the memor
Yonik,
Is this all visible on query debug level? Would it be effective to ask
to run both queries with debug enabled and to share the expanded query
value? Would that show up the differences between Lucene
implementations you described?
(Looking for troubleshooting tips to reuse).
Regards,
Al
On Thu, Sep 3, 2015 at 4:45 PM, Jeff Wartes wrote:
>
> I have a query like:
>
> q=&fq=enabled:true
>
> For purposes of this conversation, "fq=enabled:true" is set for every query,
> I never open a new searcher, and this is the only fq I ever use, so the
> filter cache size is 1, and the hit rati
I’m measuring performance in the aggregate, over several minutes and tens
of thousands of distinct queries that all use this specific fq.
The cache hit count reported is roughly identical to the number of queries
I’ve sent, so no, this isn’t a first-query cache-miss situation.
The fq result will
FQ has to calculate the result bit set for every document to be able
to cache it. Q will only calculate it for the documents it matches on
and there is some intersection hopping going on.
Are you seeing this performance hit on first query only or or every
one? I would expect on first query only un
I have a query like:
q=&fq=enabled:true
For purposes of this conversation, "fq=enabled:true" is set for every query, I
never open a new searcher, and this is the only fq I ever use, so the filter
cache size is 1, and the hit ratio is 1.
The fq=enabled:true clause matches about 15% of my docume
