Fixed Template rebuild job never finishes

TickTackk

Well-known member
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
PHP:
        \XF::db()->logQueries(false);
before
PHP:
        foreach ($templateIds AS $templateId)
and adding
PHP:
        \XF::em()->clearEntityCache();
before
PHP:
            \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...
 
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.
 
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).
 
Top Bottom