Plugin crashes website and uses massive CPU power for PHP

@andrewnyc thanks for raising this ticket! I’m sorry you had this experience. I know how frustrating it is to do debugging. Hopefully, this is an isolated case and perhaps there’s a conflict between plugins somewhere?

I’m frankly surprised about what you’re saying since nothing like this ever reported (very high CPU usage and crashes as a result of too much usage) as far as I recall. After all, the purpose of the plugin is to help you reduce the page load and consistent efforts have been made to improve the PHP processing speed as it does matter a lot when you access a page that is not cached in any way.

Last night I went to save the settings and my site crashed.

Do you recall which new settings you’ve applied before you used the save settings button?

We repeated this twice and your plugin twice followed the same pattern of spiralling php processor usage which takes the server down completely.

Are you saying you only had Asset CleanUp enabled when you experienced this? Perhaps there’s a bad conflict with one of other optimisation plugins you might have used.

Please let me know if there are any particular settings that might be causing this? I was not using CSS or JS minify, but I was inlining some CSS and defering JS load.

The most common issue that was reported (and was not affected the CPU, but the memory in specific situations) was the /wp-content/cache/asset-cleanup/ directory which became filled with lots of GB and was difficult to clean up, going through each directory/file. Users had to do it manually from their cPanel (or whatever other ways to connect to their website they had, besides the Dashboard).

Please send me your “System Info” from “Tools” (plugin’s menu) privately via https://gabelivan.com/contact/ (as it contains sensitive information).

PS: I strongly recommend you to try New Relic performance monitoring tools (some hosting companies have it available for customers, free of charge, in their package). If there’s an issue with any plugin on your end, then this tool will tell you which file/function from the plugin is causing most of the loading delays.

@andrewnyc thanks for the extra info. If you have been using the plugin for such a long time, perhaps it wrote a lot (before the caching mechanism was as effective as it is now) of files to /wp-content/cache/asset-cleanup/. Can you check that, please? If you use cPanel, consider archiving the directory as a ZIP and see if you can download it (hopefully it’s not too large). I have a suspicion that you have lots of files there from the time when the current effective cleanup mechanism wasn’t implemented. It added up and ended up being so large that is gave you that delay you were mentioning about (the spinner showing up after you clicked save).

PS: I’m very curious what’s the reason behind the issue you’ve been having. Please heck the error_log files as well that are likely reporting the exact PHP error you had in the background that led to the crashes. All I can promise is that it will get fixed immediately once I find more information about it.

@andrewnyc you can create a file with the contents <?php phpinfo(); ?> (make sure it’s only you seeing the printed information as it contains sensitive data), you will find it there. It’s usually “error_log”. See this post for more details about its possible location: https://stackoverflow.com/questions/5127838/where-does-php-store-the-error-log-php5-apache-fastcgi-cpanel

PS: There’s also a free plugin that captures the errors and prints them within the Dashboard (first page /wp-admin/) in a nice format called “Error Log Monitor”. You can set it up and future errors will be stored and printed by the plugin, no need to go through cPanel or other methods to retrieve the latest PHP errors).

@andrewnyc thanks, looking forward to it. Another way to get the path to the log file is to use <?php echo ini_get('error_log'); ?>. Consider trying that too. If it shows it, please locate it in your cPanel or via SFTP and get the latest errors printed there. The past ones (not just the recent timeout) should be there too.

PS: There’s a chance you might have had error logs turned off (not recommended). You can check that via <?php echo ini_get('log_errors'); ?>

If they are turned off, you can use something like the following code to turn them on (in your wp-config.php file)

<?php
@ini_set('log_errors', 'On');
@ini_set('error_log', '/tmp/php-errors.log'); // any accessible path you wish (make it harder to guess)
?>

@andrewnyc that’s what I needed! I’ll investigate line 469 from /classes/OptimiseAssets/CombineCssImports.php and everything connected to it until I will be sure to fix this. It could be a loop because of the way the @import is used in some of the CSS files you’re loading.

As far as I recall, I had timeout errors when I’ve been testing combining CSS imports with wrong @import data used. I experienced delays, but not the ones you mentioned (crashing the server). If you’re inlining CSS, then you might have something inside the syntax (a path taking too long to load, a relative path using ../ that was incorrectly added and PHP is confused when it deals with it, like keep trying to find it until the timeout occurs, .etc). I’ll analyse the CSS files from your website and give you an update soon. All I can promise is that this issue will be fixed for you and I will do my best to fix in such a way that no other website will experience the same issue, no matter how wrong the CSS syntax is.

PS: If you disable CSS inlining/minifying/combining, you should get the error anymore and you could use the plugin with the other features (e.g. unloaded CSS/JS files) enabled until I will fix this.

@andrewnyc good news at last! I found the culprit. It’s the way the child theme imports content from the parent theme which is incorrect (which keeps using @import on its own file) and results in an endless loop as the PHP script keeps finding new @import to read from. I can share with you more information via email if you’re interested since you might want to keep your website’s details private.

A fix will be released as soon as possible. You’ll be updated!