Hi Erick,
Yes. Apparently, there is work to do with phrase queries. As I continue
to debug, noticed that a multi word phrase query is CPU bound as it
certainly works "hard". Are there any optimizations to consider?
On 9/29/16 8:14 AM, Erick Erickson wrote:
bq: The QTimes increase as the numb
bq: The QTimes increase as the number of words in a phrase increase
Well, there's more work to do as the # of words increases, and if you
have large slops there's more work yet.
Best,
Erick
On Wed, Sep 28, 2016 at 5:54 PM, Rallavagu wrote:
> Thanks Erick.
>
> I have added queries for "firstSear
Thanks Erick.
I have added queries for "firstSearcher" and "newSearcher". After
startup, pmap shows well populated mmap entries and have better QTimes
than before.
However, phrase queries (edismax with pf2) are still sluggish. The
QTimes increase as the number of words in a phrase increase.
Hmm..
About <1>: Yep, GC is one of the "more art than science" bits of
Java/Solr. Siiih.
About <2>: that's what autowarming is about. Particularly the
filterCache and queryResultCache. My guess is that you have the
autowarm count on those two caches set to zero. Try setting it to some
modest
On 9/22/16 5:59 AM, Shawn Heisey wrote:
On 9/22/2016 5:46 AM, Muhammad Zahid Iqbal wrote:
Did you find any solution to slow searches? As far as I know jetty
container default configuration is bit slow for large production
environment.
This might be true for the default configuration that com
On 9/22/2016 5:46 AM, Muhammad Zahid Iqbal wrote:
> Did you find any solution to slow searches? As far as I know jetty
> container default configuration is bit slow for large production
> environment.
This might be true for the default configuration that comes with a
completely stock jetty downlo
Rallavagu,
Did you find any solution to slow searches? As far as I know jetty
container default configuration is bit slow for large production
environment.
On Tue, Sep 20, 2016 at 8:05 AM, Erick Erickson
wrote:
> If both queries _and_ updates are slow, it's hard to see how upping
> the number o
If both queries _and_ updates are slow, it's hard to see how upping
the number of
threads would help overall. Hmmm, you also reported that the CPUs
didn't seem to be
stressed so its worth a try, perhaps there's some kind of blocking going on
Best,
Erick
On Mon, Sep 19, 2016 at 5:33 PM, Rallav
Hi Erick,
Would increasing (or adjusting) update threads help as per this JIRA
((Allow the number of threads ConcurrentUpdateSolrClient
StreamingSolrClients configurable by a system property) here?
https://issues.apache.org/jira/browse/SOLR-8500
Thanks
On 9/19/16 8:30 AM, Erick Erickson wr
Hmmm, not sure, and also not sure what to suggest next. QTimes
measure only the search time, not, say, time waiting for the request to get
serviced.
I'm afraid the next suggestion is to throw a profiler at it 'cause nothing jumps
out at me..'
Best,
Erick
On Fri, Sep 16, 2016 at 10:23 AM, Rallava
Comments in line...
On 9/16/16 10:15 AM, Erick Erickson wrote:
Well, the next thing I'd look at is CPU activity. If you're flooding the system
with updates there'll be CPU contention.
Monitoring does not suggest any high CPU but as you can see from vmstat
output "user" cpu is a bit high durin
Well, the next thing I'd look at is CPU activity. If you're flooding the system
with updates there'll be CPU contention.
And there are a number of things you can do that make updates in particular
much less efficient, from committing very frequently (sometimes combined
with excessive autowarm para
Erick,
Was monitoring GC activity and couldn't align GC pauses to this
behavior. Also, the vmstat shows no swapping or cpu I/O wait. However,
whenever I see high update response times (corresponding high QTimes for
searches) vmstat shows as series of number of "waiting to runnable"
processes
First thing I'd look is whether you're _also_ seeing stop-the-world GC pauses.
In that case there are a number of JVM options that can be tuned
Best,
Erick
On Fri, Sep 16, 2016 at 8:40 AM, Rallavagu wrote:
> Solr 5.4.1 with embedded jetty single shard - NRT
>
> Looking in logs, noticed that
Solr 5.4.1 with embedded jetty single shard - NRT
Looking in logs, noticed that there are high QTimes for Queries and
round same time high response times for updates. These are not during
"commit" or "softCommit" but when client application is sending updates.
Wondering how updates could impac
15 matches
Mail list logo
