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=<big number here> 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 <bmi...@uship.com> 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? >
