Thanks for your replies. I've added 2 v's to the command which runs htdig
and it is now running as we speak (halfway through I guess). I'm expecting a
rather huge e-mail with the results ;-) I monitored the indexing yesterday
for a while and it looks like htdig and the other processes use some much
memory that Linux indeed has to swap to the harddrive. I'm going to ask our
service provider to add more memory.
The other thought of going to 3.2.0 did cross my mind but I've been playing
around with that one some two years ago when I tried and succesfully
compiled that version on Windows. When comparing this version with 3.1.6
I've noticed it has some performance issues. It was much slower that 3.1.6
in our tests. Worth a look if the request for extra memory is denied and the
two v's can't help me solve this problem.
Thanks again for your replies and I will be posting the results (if any :-)
From: Jim Cole <lists@yg...> - 2007-01-31 06:29:19
On Jan 17, 2007, at 12:36 AM, Marco Houtman wrote:
> The other thought of going to 3.2.0 did cross my mind but I=92ve been =20=
> playing around with that one some two years ago when I tried and =20
> succesfully compiled that version on Windows. When comparing this =20
> version with 3.1.6 I=92ve noticed it has some performance issues. It =20=
> was much slower that 3.1.6 in our tests. Worth a look if the =20
> request for extra memory is denied and the two v=92s can=92t help me =20=
> solve this problem.
I don't think that a move to 3.2 will solve any performance issues =20
related to indexing, unless it is by way of a side effect (e.g. =20
different memory usage pattern that reduces swapping). Due to feature =20=
enhancements in 3.2, such as phrase searching, the indexer must do =20
more work and manage more data. Based on all reports I have see, as =20
well as personal experience, indexing with 3.2 is significantly slower.