lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <otis_gospodne...@yahoo.com>
Subject Re: Replication Handler Severe Error: Unable to move index file
Date Thu, 21 Jan 2010 05:56:52 GMT
It's hard to tell without poking around, but one of the first things I'd do would be to look
for /home/solr/cores/core8/index.20100119103919/_6qv.fnm - does this file/dir really exist?
 Or, rather, did it exist when the error happened.

I'm not looking at the source code now, but is that really the only error you got?  No exception
stack trace?

 Otis
--
Sematext -- http://sematext.com/ -- Solr - Lucene - Nutch



----- Original Message ----
> From: Trey <solrtrey@gmail.com>
> To: solr-user@lucene.apache.org
> Sent: Wed, January 20, 2010 11:54:43 PM
> Subject: Replication Handler Severe Error: Unable to move index file
> 
> Does anyone know what would cause the following error?:
> 
> 10:45:10 AM org.apache.solr.handler.SnapPuller copyAFile
> 
>      SEVERE: *Unable to move index file* from:
> /home/solr/cores/core8/index.20100119103919/_6qv.fnm to:
> /home/solr/cores/core8/index/_6qv.fnm
> This occurred a few days back and we noticed that several full copies of the
> index were subsequently pulled from the master to the slave, effectively
> evicting our live index from RAM (the linux os cache), and killing our query
> performance due to disk io contention.
> 
> Has anyone experienced this behavior recently?  I found an old thread about
> this error from early 2009, but it looks like it was patched almost a year
> ago:
> http://old.nabble.com/%22Unable-to-move-index-file%22-error-during-replication-td21157722.html
> 
> 
> Additional Relevant information:
> -We are using the Solr 1.4 official release + a field collapsing patch from
> mid December (which I believe should only affect query side, not indexing /
> replication).
> -Our Replication PollInterval for slaves checking the master is very small
> (15 seconds)
> -We have a multi-box distributed search with each box possessing multiple
> cores
> -We issue a manual (rolling) optimize across the cores on the master once a
> day (occurred ~ 1-2 hours before the above timeline)
> -maxWarmingSearchers is set to 1.


Mime
View raw message