Timeouts during upgrades due to optimizing on posts-table

[TSP]

I work on rather large communities. We are talking about communities with 20+ million posts. 

Every now and then on upgrades I encounter this issue with gateway timeouts during the upgrade because the query to count the number of rows in the posts-table takes forever.

Ironically; one example of why it may count rows in the posts table is when it counts the number of rows in order to decide whether it should tell me to run a manual query to avoid timeouts or not... 

One example from now: 

| <Id> | <user> | <host> | <db> | Execute |  373 | optimizing | /*IPS\core\extensions\core\Queue\_RebuildSearchIndex::preQueueData:127*/ SELECT COUNT(*) FROM `ibf_forums_posts` AS `forums_posts` |

Is noone else experiencing this when doing upgrades? Seems odd this has not been resolved yet or encountered by anyone else. @Rhett, I'm sure you have some large communities on your CiC where this could happen?

[jwdenzel]

I know this is an older thread, but yeah, I have this issue as well. Every time I try to do a significant upgrade, some of my manual db commands take over an hour or much more to complete. But the upgrade UI times out and I have to start over.  I'm stuck.

Is there a way to extend the session timeout during an upgrade?

[bfarber]

On 9/18/2018 at 1:35 AM, jwdenzel said:

I know this is an older thread, but yeah, I have this issue as well. Every time I try to do a significant upgrade, some of my manual db commands take over an hour or much more to complete. But the upgrade UI times out and I have to start over.  I'm stuck.

Is there a way to extend the session timeout during an upgrade?

We use raw direct PHP sessions for the upgrader. You can extend the session timeout by using a different PHP configuration (i.e. the session-related controls in php.ini).