Hi,

I recently discovered the Recoll desktop search engine, which works rather nice. I'm running it on my workstation, and I think it's an excellent choice for finding a needle in a haystack.

Unfortunately it's quite resource hungry. This morning I installed it on a client's desktop, a rather modest Thinkcentre, and she complains that the machine is rather slow since. I checked with "top", and indeed, the 'recollindex' process eats 90% of CPU.

Any suggestions?

Niki

I have had a problem with recoll in the past. It came from postscript files. In some of them the program used to extract text (pstotext) hangs, or takes a very long time. This problem has been solved by adding an option in recoll.conf

filtermaxseconds 60

According to the manual: "Maximum handler execution time, after which it is aborted. Some postscript programs just loop..."

Thanks for that info. I'll give this a try.

More generally, I wonder if something can be done with 'nice'. More precisely, is there a way to permanently assign a low priority to a process (the 'recollindex' process here), so it's only working when all other processes are more or less idle?

It should be possible to put recollindex out of search path, and then
make a wrapper around it, where you call recollindex with the nice value you like

The script recollindex

It might work

1 members found this post helpful.

Thanks for letting me know about this engine. Should make searching a lot easier.

Nope, it won't. recollindex itself lowers its own CPU and IO priority as much as feasible. And even with a low (high) nice value, if there is nothing else which wants to run, it will take all the CPU.

After initial indexing, recollindex should sit idle (except that there are file updates). It is not at all normal that it consumes so much CPU, but it can happen in some cases for a number of reasons (maybe you found a bug).

One thing to do would be check with 'top' if it is recollindex itself which is busy or an external filter (like the postscript filter mentionned above).

The best approach would probably be to set up the debug log and take a look at what the indexer is doing, this should give a good indication. At level 3, it will only list errors and indexed file names (you can set the log from the GUI index configuration section).

There is some information about investigating indexer issues on the Faqs and HowTos pages:
https://bitbucket.org/medoc/recoll/wiki/FaqsAndHowTos

And if you can't find what's happening, you should open an issue on the tracker: https://bitbucket.org/medoc/recoll/issues

Meanwhile, maybe you should switch to periodic/batch indexing to avoid upsetting the user.