We recently upgraded to Kayako v4. After the upgrade, we were no longer able to use the search drop down under Tickets. To clarify, we can use the "Ticket ID Lookup", but we cannot use the "Creator/Replier" or "Quick Search" fields. For now, our staff has been going to the Users tab and performing a search here if we want to find all tickets for a given user. When we migrated, we ran the "Rebuild Search Index" function from within the admin area. This doesn't appear to have resolved the issue. Today, I thought I would try to re-run this from the command line in screen so I can track its progress. php ./console/index.php /Tickets/RebuildIndex/Start/ First, it looks like this script is suffering from an overflow problem: Code: [OK]: 100 processed, total: 314,000 (~19 %) in 4.135 seconds; total elapsed: 2.74 hours; mem usage: 2,093,614.17 KiB... [OK]: 100 processed, total: 314,100 (~19 %) in 34.588 seconds; total elapsed: 2.75 hours; mem usage: 2,094,269.25 KiB... [OK]: 100 processed, total: 314,200 (~19 %) in 105.541 seconds; total elapsed: 2.78 hours; mem usage: 2,094,924.77 KiB... [OK]: 100 processed, total: 314,300 (~19 %) in 11.530 seconds; total elapsed: 2.78 hours; mem usage: 2,095,579.88 KiB... [OK]: 100 processed, total: 314,400 (~19 %) in 6.922 seconds; total elapsed: 2.78 hours; mem usage: 2,096,234.96 KiB... [OK]: 100 processed, total: 314,500 (~19 %) in 6.291 seconds; total elapsed: 2.78 hours; mem usage: 2,096,890.45 KiB... [OK]: 100 processed, total: 314,600 (~19 %) in 4.376 seconds; total elapsed: 2.79 hours; mem usage: -2,096,758.51 KiB... [OK]: 100 processed, total: 314,700 (~19 %) in 5.613 seconds; total elapsed: 2.79 hours; mem usage: -2,096,103.30 KiB... [OK]: 100 processed, total: 314,800 (~19 %) in 3.281 seconds; total elapsed: 2.79 hours; mem usage: -2,095,447.89 KiB... [OK]: 100 processed, total: 314,900 (~19 %) in 5.606 seconds; total elapsed: 2.79 hours; mem usage: -2,094,792.66 KiB... [OK]: 100 processed, total: 315,000 (~19 %) in 4.908 seconds; total elapsed: 2.79 hours; mem usage: -2,094,137.40 KiB... [OK]: 100 processed, total: 315,100 (~19 %) in 6.061 seconds; total elapsed: 2.79 hours; mem usage: -2,093,481.61 KiB... Second, why does this script consume so much memory? When does it finally start freeing up some of the RAM it's using? We have 1,693,928 ticket posts: Code: [OK]: 1,693,928 ticket posts found. I let this run for just under 4 hours before having to kill it because our server started hitting swap. As soon as I killed it, 2.5GB of RAM got released. The process was only 20% complete. It seems I can expect to need at least 12GB of RAM for this process alone if this RAM consumption continues at the same rate. Code: [OK]: 100 processed, total: 343,500 (~20 %) in 4.959 seconds; total elapsed: 3.81 hours; mem usage: -1,907,355.42 KiB... [OK]: 100 processed, total: 343,600 (~20 %) in 7.320 seconds; total elapsed: 3.81 hours; mem usage: -1,906,700.24 KiB... [OK]: 100 processed, total: 343,700 (~20 %) in 7.421 seconds; total elapsed: 3.81 hours; mem usage: -1,906,044.75 KiB... [OK]: 100 processed, total: 343,800 (~20 %) in 3.140 seconds; total elapsed: 3.81 hours; mem usage: -1,905,389.25 KiB... [OK]: 100 processed, total: 343,900 (~20 %) in 3.434 seconds; total elapsed: 3.81 hours; mem usage: -1,904,734.48 KiB... Obviously, search is a function that we need to iron out. Is this a problem with the Rebuild Index function? If I saw RAM freed up at any point, I would consider performing fewer posts per run, but I used the default 100 posts and things did not go smoothly.
Hi there, If you use the console reindex, if you have to interupt it, you can use this to "start" where the indexer was stopped. php ./console/index.php /Tickets/RebuildIndex/Start/10002 Where 10002 is the number of the post the indexer last got to. ( make sure that you select no when the indexer asks if you want to flush the search engine index ) Gary
