High CPU usage from a w0rdpre55 plugin

Hi all

I know this might be a bit off topic, but today i noticed extremely high CPU usage on my main server. (High is an understatement. I’m talking about hogging 32 cores.)

I pinpointed the problem to a certain popular w0rdpre55 caching plugin that 30-something sites on my server are using.

The problem is that the plugin initiates it’s “preload” feature every few minutes, and hogging disk and CPU usage. One instance would be unnoticed, but this became an epidemic. :frowning:

Does anyone have a similar issue? Maybe can share a pointer how to block a certain plugins ugly feature server wide? (I’m not a w0rdpre55 expert.)

This is a major premium caching plugin without an open forum, so I can’t rant publicly. :slight_smile:

BR,
Neven

I use on default Proxy cache + Hestia Nginx Cache – WordPress plugin | WordPress.org or fastcgi cache + hestia-nginx-cache and it works like a charm

I could force it as MU plugin, but how to discourage customers from using that idiotic “other” plugin that rimes with: wp-pocket. :slight_smile:

You need to do website optimization by relacing highly hungery plugins/themes with low consuming ones, disabling plugin scripts on pages that don’t need to be on, and optimizing images. A quick start is to look at the issues in Google PageSpeed report.

I had similar issues for my website two months ago. I did optimize it until the website is loading fast, which is now passing core web vitals in Google.

Disable wp-rocket plugin:

add_filter( 'option_active_plugins', function( $plugins ) {
    if ( get_current_blog_id() !== 1 ) {
        $plugin = 'plugin-name/plugin-name.php';
        $key = array_search( $plugin, $plugins );
        if ( $key !== false ) {
            unset( $plugins[ $key ] );
        }
    }

    return $plugins;
});

substitute plugin-name for wp-rocket

Alternatively you may create a watchdog.

Monitor CPU and all the high-consuming users and slay them or suspend them
#apt install slay
#slay username
Slay kills all the processes belonging to username.

1 Like

Thanks! Now that’s more in line with what I was contemplating. :heart_eyes:

Watchdog slaying idea I especially like, but since I’m hosting mostly webshops, that might be a little bit too brutal.

Filter would work, but I was thinking more about something on the server side… like blocking offending local GET requests made from this plugin, or just put it in the ClamAV database. :smiling_imp:

It seems that cache preloading of the entire site can be triggered by certain actions from a client, which is a major security issue with this plugin.

Fast cgi / proxy cache might not work ideally with webshop try it out first