It might be worth checking the VMWare environment - if you're using the VMWare scsi vmdk and it's shared across multiple VMs and there's a lot of disk contention (i.e. multiple VMs are all busy reading/writing to/from the same disk channel), this can really slow down I/O operations.
On Tue, May 4, 2010 at 8:52 AM, Markus Fischer <mar...@fischer.name> wrote: > Hi, > > > On 04.05.2010 03:24, Mark Miller wrote: > >> On 5/3/10 9:06 AM, Markus Fischer wrote: >> >>> we recently began having trouble with our Solr 1.4 instance. We've about >>> 850k documents in the index which is about 1.2GB in size; the JVM which >>> runs tomcat/solr (no other apps are deployed) has been given 2GB. >>> >>> We've a forum and run a process every minute which indexes the new >>> messages. The number of messages updated are from 0 to 20 messages >>> average. The commit takes about 1 or two minutes, but usually when it >>> finished a few seconds later the next batch of documents is processed >>> and the story starts again. >>> >>> Our environment is being providing by a company purely using VMWare >>> infrastructure, the Solr index itself is on an NSF for which we get some >>> 33MB/s throughput. >>> >> >> That is certainly not a normal commit time for an index of that size. >> >> Note that Solr 1.4 can have issues when working on NFS, but I don't know >> that it would have anything to do with this. >> >> Are you using the simple lock factory rather than the default native >> lock factory? (as you should do when running on NFS) >> > > I've switched the lockType to "simple" but didn't see any timing > difference; it's still somewhat between one or two minutes. > > In my last test case I tested with the indexing having been updated with > only a single document. > > I'm not very familiar with getting more debug information or similar out of > Solr; is there a way to enable something to find out what's actually doing > and what costs much time? > > thanks so far, > - Markus > >
