You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by Brian Whitman <br...@variogr.am> on 2007/12/19 15:23:01 UTC
debugging slowness
We've got periods where direct solr queries take 35s; on resin reboot
they go back to taking 500ms. This is on a 16GB ram 4-core server. We
want to debug this but don't know where to start. Is there some sample-
type command we can run during queries to figure out where Solr/Lucene
is spending its time (ala MySQL's slow query log)?
Re: debugging slowness
Posted by Yonik Seeley <yo...@apache.org>.
On Dec 19, 2007 9:48 AM, Brian Whitman <br...@variogr.am> wrote:
>
> On Dec 19, 2007, at 9:34 AM, Yonik Seeley wrote:
>
> > On Dec 19, 2007 9:23 AM, Brian Whitman <br...@variogr.am>
> > wrote:
> >> It's pretty easy to parse access logs or solr query logs and find the
> > offenders (I don't have any parsing code at my fingertips though...)
> >
> > Do these periods of slowness tend to happen right after a commit?
> > Do the slow queries have anything in common?
>
> All queries become slow, so looking at the access logs don't help us
> much.
You could try thread dumps (kill -3, or use the solr admin page)
The latest devel versions of solr also break out time by component if
you give debugQuery=true
> After some amount of time (variable, but measured in days) Solr
> just becomes slow for us, every query takes 20-30s.
This is strange (if a reboot fixes it).
Anything odd in the logs? overlapping searchers? search for
"WARNING" in the logs.
Also check to make sure it's not a GC... that could cause everything
to start slowing down when you start running out of memory.
-Yonik
Re: debugging slowness
Posted by Brian Whitman <br...@variogr.am>.
On Dec 19, 2007, at 9:34 AM, Yonik Seeley wrote:
> On Dec 19, 2007 9:23 AM, Brian Whitman <br...@variogr.am>
> wrote:
>> It's pretty easy to parse access logs or solr query logs and find the
> offenders (I don't have any parsing code at my fingertips though...)
>
> Do these periods of slowness tend to happen right after a commit?
> Do the slow queries have anything in common?
All queries become slow, so looking at the access logs don't help us
much. After some amount of time (variable, but measured in days) Solr
just becomes slow for us, every query takes 20-30s. I was looking for
more code-level sampling/logging (to see if I could fix it.) Or at
least see if it's a resin thing vs. a solr thing.
The index in question has a 15m autocommit and gets about 1-3 new
documents/second.
Re: debugging slowness
Posted by Yonik Seeley <yo...@apache.org>.
On Dec 19, 2007 9:23 AM, Brian Whitman <br...@variogr.am> wrote:
> We've got periods where direct solr queries take 35s; on resin reboot
> they go back to taking 500ms. This is on a 16GB ram 4-core server. We
> want to debug this but don't know where to start. Is there some sample-
> type command we can run during queries to figure out where Solr/Lucene
> is spending its time (ala MySQL's slow query log)?
It's pretty easy to parse access logs or solr query logs and find the
offenders (I don't have any parsing code at my fingertips though...)
Do these periods of slowness tend to happen right after a commit?
Do the slow queries have anything in common?
-Yonik