Rebuild Post Index?

[Ronny]

I'm trying to do Rebuild Post Index and no matter what, whether the value is 1, 5, 20 or 200, I always get page cannot be displayed. It never goes past 15%

I do have a lot of posts etc, could this be the problem?

Is there a way to run it manually and not through the browser? Perhaps that will help.

This is seriously ffecting our helpdesk as our search is practically useless.

[Varun Shoor]

This is usually due to mod_dosevasive, You can toggle the refresh timing under modules/tickets/admin_maintenaince.php line 155, Changing it from default 500 to 6000 (6 Seconds) should resolve the issue.

Regards,

Varun Shoor

[tky]

Is there any other workaround? I've tried all the tips mentioned in here and my search index is still unable to be built. After a few minutes or hours, the small popup window with the build status just goes white -- it never, ever completes.

Can the index be built in any other way, possibly outside the web environment? We've been crippled in a huge way due to this problem. Any advice appreciated.

[tky]

Well, looks like I solved my own problem. I got tired of waiting for support to get around to helping me, so I tore apart as much of Kayako as possible to figure out how the search indexer actually works. Here's what I sent back to the support folks, which summarizes my problem, its solution, and my agreement with many others that 3.0 is very far from what I'd consider production grade software. I hope this helps someone who is having similar issues:

I decided that it was easier for me to tear Kayako apart than spend more time waiting. Even giving you access wouldn't have gotten us anywhere. In the end, Kayako's search updater falls over on tickets with large number of replies - it should gracefully skip tickets with say, 500+ replies (accidental, caused by autoresponder - which is another thing Kayako should have: mail loop prevention)

To solve the problem, I simply:

- Upped the amount of memory PHP could use
- Increased time until PHP kills lingering processes
- Used mysqladmin to perform a show processlist; every second

Then I modified my browser setting so that the network timeout was higher (9 minutes) instead of the default, which I believe is 30 seconds.

By performing a search index update and carefully watching the processlist output, I was able to determine that the index update failed at the exact same time each run. I then waited until it got close to the same failure point and noted the ticket ID it was working on as displayed in the processlist output. Manually removing the ticket from the database and re-running the update finally got it to work.

I'll post this to the message boards as well, since there's a ridiculous number of people having problems with search and/or support getting back to them in a timely fashion.

While reading the boards, I couldn't help but find myself in agreement with others that I felt somewhat duped into buying and installing the upgrade, and only found *after* the fact that 3.0 is very far from production level. Bugs are fine, but this isn't production level by any means whatsoever.

[HostDime]

tky, thank you for posting the useful information.

We have a kaykao license with over 10,000 tickets and a DB size of 7GB

We are looking to upgrade it to version 3.0 but it appears not to be such a good idea?


Can someone from kayako please post if these issues have been fixed?

I have a feeling this search issue will kill us. Especially re-indexing our database which is above normal size!!

[Hiren]

Originally Posted by HostDime

tky, thank you for posting the useful information.

We have a kaykao license with over 10,000 tickets and a DB size of 7GB

We are looking to upgrade it to version 3.0 but it appears not to be such a good idea?


Can someone from kayako please post if these issues have been fixed?

I have a feeling this search issue will kill us. Especially re-indexing our database which is above normal size!!

Hi,
I do not believe it should be an issue. We ourselves have 10k+ tickets and have had no problems re-indexing. Clearing your asParserLog and asAttachments tables will reduce your database size considerably.

Regards,

Hiren Mehta

[tky]

Originally Posted by HostDime

I have a feeling this search issue will kill us. Especially re-indexing our database which is above normal size!!

It isn't so much the size as much as it is the error handling capabilities. I would proceed with caution, testing an upgrade on a non-production host first. For everyone that says it's okay and "works fine here!" there are plenty of us out there encountering these problems repeatedly. Good luck!!

[xyzed]

Originally Posted by Hiren [K]

Hi,
I do not believe it should be an issue.

Well it's an issue for us to. Over 31,000 inital tickets plus replies and still never been able to do this without errors.

Helpdesk has been moved to dual Opteron with 4GB and only running the helpdesk and still has the same problem.


X.

[xyzed]

Here are the most common 2 errors:

Fatal error: Maximum execution time of 30 seconds exceeded in /modules/tickets/functions_search.php on line 160

Fatal error: Maximum execution time of 30 seconds exceeded in /modules/tickets/functions_search.php on line 153

There are other lines that appear from time to time, but those 2 are the common ones.

Does not matter if set anywhere from 1 to 100 same error will occur.

I've also deleted tens of thousands of posts to help, but still the same error. Parserlogs and attachements are also all cleared.

[mcjack]

Edit your /etc/php.ini and do this:

#Increase the maximum execution time of your php scripts to
#something more comfortable say 50
max_execution_time = 50

And search for everything containing "timeout" in your php.ini and just increase.

Mind you just search for "Maximum execution time of 30 seconds exceeded" in google.