Hi Brent,
You said "from what I can tell there is no disk, network, or memory pressure "
- maybe you can share what and how you checked this? (see my signature for
a tool that can help with this)
I'm asking because the above is in conflict with "responses from solr still
come back with a <10ms qtime", which indicate search itself was fast, but
either disk or network were slow. Try with rows= and
rows=0 and that will give you an idea where to look.
Otis
--
SOLR Performance Monitoring - http://sematext.com/spm/index.html
On Mon, Dec 17, 2012 at 1:04 AM, Brent Mills wrote:
> This is an issue we've only been running into lately so I'm not sure what
> to make of it. We have 2 cores on a solr machine right now, one of them is
> about 10k documents, the other is about 1.5mil. None of the documents are
> very large, only about 30 short attributes. We also have about 10
> requests/sec hitting the smaller core and less on the larger one. Whenever
> we try to do a full import on the smaller one everything is fine, the
> response times stay the same during the whole 30 seconds it takes to run
> the indexer. The cpu also stays fairly low.
>
> When we run a full import on the larger one the response times on all
> cores tank from about 10ms to over 8 seconds. We have a 4 core machine
> (VM) and I've noticed 1 core stays pegged the entire time which is
> understandable since the DIH as I understand it is single threaded. Also,
> from what I can tell there is no disk, network, or memory pressure (8gb)
> either and the other procs do virtually nothing. Also the responses from
> solr still come back with a <10ms qtime. My best guess at this point is
> tomcat is having issues when the single proc gets pegged but I'm at a loss
> on how to further diagnose this to a tomcat issue or something weird that
> solr is doing.
>
> Has anyone run into this before or have ideas about what might be
> happening?
>