Apologies.About this osTicket InstallationServer InformationosTicket Version v1.9.7 (4be5782) Web Server Software Microsoft-IIS/7.5 MySQL Version 5.5.37 PHP Version 5.3.28 PHP Extensionsgdlib  Used for image manipulation and PDF printing  imap  Used for email fetching  xml  XML API  xml-dom  Used for HTML email processing  json  Improves performance creating and processing JSON  mbstring  Highly recommended for non western european language content  phar  Highly recommended for plugins and language packs  fileinfo  Used to detect file types for uploads  PHP Settingscgi.fix_pathinfo  "1" is recommended if AJAX is not working  date.timezone  America/Denver  Database Information and UsageSchema ossupport (localhost)  Schema Signature b26f29a6bb5dbb3510b057632182d138  Space Used 40262.14 MiB Space for Attachments 

I'm getting these PHP errors as well in my error log.

PHP Fatal error:  Uncaught exception 'Exception' with message 'Unable to index content' in ...osticket19\include\class.search.php

Stack trace:

#0 ...osticket19\include\class.search.php(507): MysqlSearchBackend->__index(Array)

#1 : MysqlSearchBackend->IndexOldStuff(Array, NULL)

#2 ...osticket19\include\class.signal.php(98): call_user_func_array(Array, Array)

#3 ...osticket19\scp\autocron.php(58): Signal:('cron', Array)

#4 {main}

  thrown in ...osticket19\include\class.search.php on line 633

PHP Fatal error:  Uncaught exception 'Exception' with message 'Unable to index content' in ...osticket19\include\class.search.php

Stack trace:

#0 ...osticket19\include\class.search.php(507): MysqlSearchBackend->__index(Array)

#1 : MysqlSearchBackend->IndexOldStuff(Array, NULL)

#2 ...osticket19\include\class.signal.php(98): call_user_func_array(Array, Array)

#3 ...osticket19\scp\autocron.php(58): Signal:('cron', Array)

#4 {main}

  thrown in ...osticket19\include\class.search.php on line 633

PHP Fatal error:  Uncaught exception 'Exception' with message 'Unable to index content' in ...osticket19\include\class.search.php

Stack trace:

#0 ...osticket19\include\class.search.php(507): MysqlSearchBackend->__index(Array)

#1 : MysqlSearchBackend->IndexOldStuff(Array, NULL)

#2 ...osticket19\include\class.signal.php(98): call_user_func_array(Array, Array)

#3 ...osticket19\scp\autocron.php(58): Signal:('cron', Array)

#4 {main}

  thrown in ...osticket19\include\class.search.php on line 633

PHP Fatal error:  Uncaught exception 'Exception' with message 'Unable to index content' in ...osticket19\include\class.search.php

Stack trace:

#0 ...osticket19\include\class.search.php(507): MysqlSearchBackend->__index(Array)

#1 : MysqlSearchBackend->IndexOldStuff(Array, NULL)

#2 ...osticket19\include\class.signal.php(98): call_user_func_array(Array, Array)

#3 ...osticket19\scp\autocron.php(58): Signal:('cron', Array)

#4 {main}

  thrown in ...osticket19\include\class.search.php on line 633

PHP Fatal error:  Uncaught exception 'Exception' with message 'Unable to index content' in ...osticket19\include\class.search.php

Stack trace:

#0 ...osticket19\include\class.search.php(507): MysqlSearchBackend->__index(Array)

#1 : MysqlSearchBackend->IndexOldStuff(Array, NULL)

#2 ...osticket19\include\class.signal.php(98): call_user_func_array(Array, Array)

#3 ...osticket19\scp\autocron.php(58): Signal:('cron', Array)

#4 {main}

  thrown in ...osticket19\include\class.search.php on line 633

PHP Fatal error:  Uncaught exception 'Exception' with message 'Unable to index content' in ...osticket19\include\class.search.php

Stack trace:

#0 ...osticket19\include\class.search.php(507): MysqlSearchBackend->__index(Array)

#1 : MysqlSearchBackend->IndexOldStuff(Array, NULL)

#2 ...osticket19\include\class.signal.php(98): call_user_func_array(Array, Array)

#3 ...osticket19\scp\autocron.php(58): Signal:('cron', Array)

#4 {main}

  thrown in ...osticket19\include\class.search.php on line 633

PHP Fatal error:  Uncaught exception 'Exception' with message 'Unable to index content' in ...osticket19\include\class.search.php

Stack trace:

#0 ...osticket19\include\class.search.php(507): MysqlSearchBackend->__index(Array)

#1 : MysqlSearchBackend->IndexOldStuff(Array, NULL)

#2 ...osticket19\include\class.signal.php(98): call_user_func_array(Array, Array)

#3 ...osticket19\scp\autocron.php(58): Signal:('cron', Array)

#4 {main}

  thrown in ...osticket19\include\class.search.php on line 633

PHP Fatal error:  Uncaught exception 'Exception' with message 'Unable to index content' in ...osticket19\include\class.search.php

Stack trace:

#0 ...osticket19\include\class.search.php(507): MysqlSearchBackend->__index(Array)

#1 : MysqlSearchBackend->IndexOldStuff(Array, NULL)

#2 ...osticket19\include\class.signal.php(98): call_user_func_array(Array, Array)

#3 ...osticket19\scp\autocron.php(58): Signal:('cron', Array)

#4 {main}

  thrown in ...osticket19\include\class.search.php on line 633

I think I may have figured out what is going on, but would like some clarification if possible.I believe this query is indexing ticket notes (threads).  It appears to be running randomly when using the system.  I know this function is generated in class.search.php for Threads search (indexing?).  We are upgrading from 1.6 ST to 1.9 (latest) and so it's needing to build (and populate) these new index tables with our gazillion tickets and notes/threads.  I believe I see in class.search.php that it should be limiting the "batch" of each of these to either 20 or 60, but it appears to be "indexing" thousands of entries at a time (watching how our ost__search table is growing).So my question is:Is it actually indexing things? (I've never seen indexing, so I have to guess this is what is happening)Is this search indexing working the way it should based on the errors provided above?Once everything is indexed, will it stop running these table-locking queries (or at least decrease them from the current 1 to 3 minute queries to 1 to 2 seconds?)How does the "index" start occur (is it by user activity?)How much is supposed to index with each query when the system is working correctly?  Is there a way to force it to index all at one time, rather than do some indexing based on user activity, OR is it possible to limit the indexing to only a couple rows at a time so it doesn't lock down the whole system while it's doing this?Thank you for any help or clarification!!

@[deleted] I haven't had any negative speed issues w/OsTicket but I did with another application I was using.  A query would run past 120 seconds which wasn't going to cut it in a production environment with other users and processes going on at the same time.  Via phpMyAdmin I created a few indexes on tables that had a lot of data and that were also joining other tables.  I was able to bring a 120 second execution down to < 0.5

Unfortunately I'm not so deep into the osTicket code, but I'll point this threads to the developers since they should know best ;)

I've already sent it to the devs. :)

Guess they'll then receive it twice ;)

Thank you for checking on this - Don't know if this helps, but it's showing the table being locked until the others finish.blank

12 days later

Good morning - just wanted to see if the devs had a chance to look into this.  Our system can't be used effectively until this is resolved.Thank you!

I do not see a reply from the devs here.  I will ping them again.

@[deleted],My guess is that you have a one minute scheduled cron and several users using the system. It looks like the search indexer runs on both the autocron and on the scheduled cron. I would recommend we disable the indexer from the autocron — at least on your system. Perhaps you could add / change this code in the `class.search.php` to disable the indexer for the autocron:    /** 

     * Cooperates with the cron system to automatically find content that is

     * not index in the _search table and add it to the index.

     */

    function IndexOldStuff($signal) {

        if ($signal)

            return;

        $class = get_class();

        $auto_create = function($db_error) use ($class) {

That is, change the IndexOldStuff function definition to receive `$signal` and add the `if` statement to the function prologue.

16 days later

It looks like that may have done it - weird though - I have no one minute cron set up and have the auto-cron off (that I know of!).Thank you for your help!

3 months later

@[deleted]How can I disable indexoldstuff for regular cron calls (i.e. using a BAT file)?   This is still being kicked off whenever we try to run our cron, but is disabled when using autocron.

I think I've resolved this by changing reindex to false:    function bootstrap() {        if ($this->getConfig()->get('reindex', false))            Signal:('cron', array($this, 'IndexOldStuff'));    }What will changing this to false actually do?  This did prevent that db killing query from kicking off.

8 months later

Sorry to revive this older thread, It was linked in a support thread I opened for basically the same issue.I am seeing the same issues as @[deleted]I am coming from version 1.6RC2 to version 1.9.12, over 150,000 tickets.Upgrade process goes great, system is very responsive, but seems to slow down greatly when populating the ost__search table.the count on ost__search only seems to increase when someone either opens a ticket, replies, or closes a ticket, and it increases by a couple thousand each time. I left our system running all weekend and there was no change to ost__search row count. I do not mind the system being slow for a while, but it would be much better if there was some way to force the system to just fully index itself once upgraded to prevent any slowdowns once in production.The only thing preventing us from upgrading right now is this slow down that occurs sometimes when opening tickets, etc.If I could upgrade it over the weekend, and fully index it before Monday, that would be perfect.I look forward to hearing back from you guys.thanks

Write a Reply...