High CPU on /wp-admin/load-styles.php

All that code does is check if theme.json is readable and if not assign a registered file’s handle to an array of dependencies. Nothing that would warrant 100% usage. Typically in such a situation high usage would be a result of a theme or plugin hooking into the process and doing something much more extensive.

I see you said there’s nothing else in common between the problem sites. Have you also checked for must-use plugins that may be in common?

Even the loading of the dependent file (done elsewhere) wouldn’t consume much resource, the file is only 2kB in size.

It could be a “straw that broke the camel’s back” situation. Something else prior consumes much resource and this little bit extra was all it took to kick things over the limit.

• This reply was modified 1 year, 7 months ago by bcworkz.

Thanks,

It does more than that, it calls two other functions “get_stylesheet_directory” and “get_template_directory”. Both functions are pretty simple, but both call WP filters. If I edit the functions to return before running the filters. The problem goes away.

So I’m thinking there may be a random filter loop somewhere?? However, bizarrely it started happening on multiple sites at the same time. One of the sites is an existing site I picked up hosting for a new client. It is DIVI theme based and has none of the plugins that I normally use.

So when I added it to my ManageWP, the ManageWP client is the only plugin in common. I tried disabling MangeWP and the problem persisted.

“ManageWP – Worker Loader” is the only MU plugin that gets disabled when I disable Manage WP.

Even stranger, the issue is intermittent. Once I end the mentioned processes, the site works perfectly fine again until it breaks again at some random interval.

OK, update, It just occurred on a site.

It looks like it may be the filter ‘template_directory’

In /wp-includes/theme.php line 327 – function get_template_directory():

If I add “return $template_dir” on line 331, it resolves the problem.

So I think something may be looping on the filter ‘template_directory’. It is just so odd that it is suddenly occurring on multiple sites that have never had this issue before. Perhaps if there were common themes or plugins on all affected sites, but there isn’t.

More details, I created a simple plugin to log a debug backtrace for the above-mentioned details.

When the issue occurs, what I’m seeing is a continuous loop until I kill the account processes see the example below. This just continuously repeats.

[
{
"file": "\/home\/chauffeured\/public_html\/wp-includes\/class-wp-hook.php",
"line": 308,
"function": "{closure}"
},
{
"file": "\/home\/chauffeured\/public_html\/wp-includes\/plugin.php",
"line": 205,
"function": "apply_filters",
"class": "WP_Hook",
"type": "->"
},
{
"file": "\/home\/chauffeured\/public_html\/wp-includes\/theme.php",
"line": 205,
"function": "apply_filters"
},
{
"file": "\/home\/chauffeured\/public_html\/wp-includes\/l10n.php",
"line": 1281,
"function": "get_stylesheet_directory"
},
{
"file": "\/home\/chauffeured\/public_html\/wp-includes\/l10n.php",
"line": 1305,
"function": "_load_textdomain_just_in_time"
},
{
"file": "\/home\/chauffeured\/public_html\/wp-includes\/l10n.php",
"line": 187,
"function": "get_translations_for_domain"
}
]

I’m glad you were somewhat successful in further isolating the problem. Unfortunately, none of that tells us exactly which filter callback is causing the problem. Intermittent problems are notoriously difficult to debug. Ideally you’d find some way to reliably induce the problem to occur so the problem can be isolated by process of elimination.

You could instead temporarily hack class-wp-hook.php a little bit to log what callback it’s currently executing. If the callback is crashing the process, it’ll be the last one logged. However, the callback appears to be a closure. The name logged will just be a hash value and not very useful in isolating the problem callback.

Just knowing it’s a closure does help some. There might not be too many closures hooked to “template_directory”. Do a full text recursive search of the code base using utilities like grep or findstr. Locate all add_filter() calls for “template_directory” that involve closures (anonymous functions). Comment out each of the ones found, one at a time, to see if it resolves the problem. With intermittent problems you’ll have to wait a while before you’re confident the problem was resolved. Eventually you’ll isolate the culprit.

In the mean time, whatever template directory was being filtered will cease to function properly. You likely don’t want a site to be partly broken for an extended period. You may want to create a test site that you can experiment on. The WP_Staging plugin makes doing this quick and painless. Doing so manually isn’t really that difficult either, especially when you don’t need the same content.

Hey, Just a heads up. I’m suspecting a Litespeed server issue.

I didn’t pick this up earlier, but 2 weeks ago the team that manages our servers updated Litespeed. We have a 4 worker license.
However, using htop, I see that when the issue occurs only 1 CPU core goes to 100% and just stays there.

I have a ticket in for them to check the active license. God I hope it is just that.