Hi, I use ferret 0.10.4 whith shared index over NFS directory. There are 2 applications servers. The web server is Mongrel 0.3.13.3 and mongrel_cluster 0.2.0. There are 20 Mongrel processes on each server. Each time my application update a model, Mongrel process stops running with this errro in its log: /usr/lib/ruby/gems/1.8/gems/ferret-0.10.4/lib/ferret/index.rb:663: [BUG] Segmentation fault Theses servers are serving a lot of requests. Is it good to have shared NFS index ? Is there a lock problem ? This is very urgent. 10000 thanks for any help. Regards Seb
Hi! On Sat, Sep 16, 2006 at 12:53:48PM +0200, Sebastien Hugues wrote:> Hi, > > I use ferret 0.10.4 whith shared index over NFS directory. > There are 2 applications servers. The web server is Mongrel 0.3.13.3 > and mongrel_cluster 0.2.0. There are 20 Mongrel processes on each > server. > > Each time my application update a model, Mongrel process > stops running with this errro in its log: > > /usr/lib/ruby/gems/1.8/gems/ferret-0.10.4/lib/ferret/index.rb:663: > [BUG] Segmentation fault > > Theses servers are serving a lot of requests. Is it good to have > shared NFS index ? Is there a lock problem ?Possible that there are locking problems. We had this question come up some days ago on the list, hope Dave can shed some light on this. I''m working on remote indexing capabilities for acts_as_ferret right now. Atm I have a little drb server that does the indexing/searching, and an experimental branch of acts_as_ferret that can talk to this server. So you''d only have one index and both machines talking to this. Drop me line if you''re interested in a solution like this. Jens -- webit! Gesellschaft f?r neue Medien mbH www.webit.de Dipl.-Wirtschaftsingenieur Jens Kr?mer kraemer at webit.de Schnorrstra?e 76 Tel +49 351 46766 0 D-01069 Dresden Fax +49 351 46766 66
FYI, it is a long time known issue between Java Lucene and NFS mounted file systems. There is actually quite a bit of active work going on in this space in the Java Lucene community. Erik On Sep 17, 2006, at 7:07 AM, Jens Kraemer wrote:> Hi! > On Sat, Sep 16, 2006 at 12:53:48PM +0200, Sebastien Hugues wrote: >> Hi, >> >> I use ferret 0.10.4 whith shared index over NFS directory. >> There are 2 applications servers. The web server is Mongrel 0.3.13.3 >> and mongrel_cluster 0.2.0. There are 20 Mongrel processes on each >> server. >> >> Each time my application update a model, Mongrel process >> stops running with this errro in its log: >> >> /usr/lib/ruby/gems/1.8/gems/ferret-0.10.4/lib/ferret/index.rb:663: >> [BUG] Segmentation fault >> >> Theses servers are serving a lot of requests. Is it good to have >> shared NFS index ? Is there a lock problem ? > > Possible that there are locking problems. We had this question come up > some days ago on the list, hope Dave can shed some light on this. > > I''m working on remote indexing capabilities for acts_as_ferret right > now. Atm I have a little drb server that does the indexing/searching, > and an experimental branch of acts_as_ferret that can talk to this > server. > So you''d only have one index and both machines talking to this. > Drop me > line if you''re interested in a solution like this. > > > Jens > > > > -- > webit! Gesellschaft f?r neue Medien mbH www.webit.de > Dipl.-Wirtschaftsingenieur Jens Kr?mer kraemer at webit.de > Schnorrstra?e 76 Tel +49 351 46766 0 > D-01069 Dresden Fax +49 351 46766 66 > _______________________________________________ > Ferret-talk mailing list > Ferret-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/ferret-talk
Jens Kraemer wrote:> Hi! > On Sat, Sep 16, 2006 at 12:53:48PM +0200, Sebastien Hugues wrote: >> /usr/lib/ruby/gems/1.8/gems/ferret-0.10.4/lib/ferret/index.rb:663: >> [BUG] Segmentation fault >> >> Theses servers are serving a lot of requests. Is it good to have >> shared NFS index ? Is there a lock problem ? > > Possible that there are locking problems. We had this question come up > some days ago on the list, hope Dave can shed some light on this. > > I''m working on remote indexing capabilities for acts_as_ferret right > now. Atm I have a little drb server that does the indexing/searching, > and an experimental branch of acts_as_ferret that can talk to this > server. > So you''d only have one index and both machines talking to this. Drop me > line if you''re interested in a solution like this.An alternative and IMO better solution is to disable indexing in the Rails app and use an external process that periodically reindexes changed (updated_at > last_update) records. This has the additional advantage that the index update can''t block or crash the Rails app servers. -- Posted via http://www.ruby-forum.com/.
On Mon, Sep 18, 2006 at 09:09:07AM +0200, Andreas Schwarz wrote:> Jens Kraemer wrote: > > Hi! > > On Sat, Sep 16, 2006 at 12:53:48PM +0200, Sebastien Hugues wrote: > >> /usr/lib/ruby/gems/1.8/gems/ferret-0.10.4/lib/ferret/index.rb:663: > >> [BUG] Segmentation fault > >> > >> Theses servers are serving a lot of requests. Is it good to have > >> shared NFS index ? Is there a lock problem ? > > > > Possible that there are locking problems. We had this question come up > > some days ago on the list, hope Dave can shed some light on this. > > > > I''m working on remote indexing capabilities for acts_as_ferret right > > now. Atm I have a little drb server that does the indexing/searching, > > and an experimental branch of acts_as_ferret that can talk to this > > server. > > So you''d only have one index and both machines talking to this. Drop me > > line if you''re interested in a solution like this. > > An alternative and IMO better solution is to disable indexing in the > Rails app and use an external process that periodically reindexes > changed (updated_at > last_update) records. This has the additional > advantage that the index update can''t block or crash the Rails app > servers.Right, depending the exact application this may be a better solution. Plus you''d get better performance with batch-indexing new/updated records. but, if an index update crashes your rails server, it''ll most likely crash your background indexer, too - you''re just moving the problem away from the surface. Of course, having a stale index but the rest of the app working is better than having the whole app crashed ;-) In addition, the index won''t be guaranteed to be always up to date, and deleted records will have to be handled, maybe by flagging them as deleted instead of really deleting them. Jens -- webit! Gesellschaft f?r neue Medien mbH www.webit.de Dipl.-Wirtschaftsingenieur Jens Kr?mer kraemer at webit.de Schnorrstra?e 76 Tel +49 351 46766 0 D-01069 Dresden Fax +49 351 46766 66