Fixed Template rebuild job never finishes

[TickTackk]

Affected version

2.2.0

When installing new style on a board with many big add-ons, there is a manual job pending but it almost never succeeds. After lots of blind testing, adding

        \XF::db()->logQueries(false);

before

        foreach ($templateIds AS $templateId)

and adding

        \XF::em()->clearEntityCache();

before

            \XF::dequeueRunOnce('styleLastModifiedDate'); // we'll update this later

in /<path to xf>/src/XF/Job/TemplateRebuild.php seems to fix the issue for me.

My guess is that it is the phrases which ends up eating the memory but I could be wrong...

 

[XF Bug Bot]

Thank you for reporting this issue, it has now been resolved. We are aiming to include any changes that have been made in a future XF release (2.2.5).

Change log:

Reduce peak memory usage when executing certain template/phrase rebuild jobs.

There may be a delay before changes are rolled out to the XenForo Community.

 

[Mike]

So I think this is actually configuration specific and doing something that isn't something we expect/recommend, though it ended up being fairly simple to resolve.

I'm guessing that you've increased jobMaxRunTime, probably fairly sizably. (This might actually tie into a separate bug report you made.) We don't generally expect this to be raised to a large number -- the primary use case for the config option is actually to reduce it for problematic servers.

This likely allowed the parent XF:Atomic job to run for much longer than it normally would and thus the entity cache would build up more content. To be honest, this did take up more space per template than I expected, so clearing the cache after a run does resolve the issue and keeps the memory usage much more reasonable.

But ultimately, I suspect there might have been a jobMaxRunTime change which was the main catalyst (and likely why I don't think we've seen a report like this in production very often).