Automated scans on multiple sites all start exactly same time, killing CPU

hey Caleb – no, they’re not all mine, they’re all quite different in terms of functionality, plugins etc, and I need the ability to move/migrate sites easily. I’m (definitely) no multisite expert, but I’ve made the decision in the past that it’s not the right solution in my case.
Using separate WP instances has been fine in the past (with centralised plugin/theme management etc), but this recent WF update appears to have generated a new problem.

Thanks for your reply though

thanks @wfyann
Yes the cron job times in Diagnostics do correspond to the times when it grinds to a halt.

But that gave me another thought (this might well be what you’re getting at) – as a test, I’ve just checked ‘Delete Wordfence tables and data on deactivation’ and then gone ahead and deactivated/reactivated Wordfence – and that cron job is now scheduled for a different (albeit apparently random) time/day.

So I guess it’s possible to effectively force wordfence to choose a different scan schedule – it’s a bit nasty, but it might help to get round the problem…

thanks for looking, any further thoughts appreciated

thanks @wfyann – I’ve sent you diagnostics reports from 3 sites via email.

Hi @trademark2k6

You might not need to actually delete the plugin – I seem to remember that if you select ‘Delete Wordfence Tables and Data on deactivation’ – and then deactivate and reactivate the plugin, this will cause the scheduled scan time to regenerate.

If you check the timing of the ‘wordfence_start_scheduled_scan’ cron job (within Tools – Diagnostics – Cron Jobs) before and after de/reactivation, you should see that the time has changed.

Do that on 4 of your 5 sites, and the scheduled scan times should all be different.

And on your other question, I always see two ‘wordfence_start_scheduled_scan’ cron jobs, as if two are always scheduled, usually 3 days apart. Normal, as far as I know.

Hope that helps – just bear in mind that using this method will mean that you’ll need to reconfigure your WF settings if you were using anything customised.

Hi @trademark2k6, no problem

Well, these are only my observations, having used WF on a number of sites, so it is just my opinion, but:
– I guess there’s no harm in staggering when you do the de/reactivation, although I’m not actually convinced that there’s a link between when you reactivate, and what the scheduled scan start time is – i.e. if you did two sites at once, I don’t think that will necessarily result in the same schedule time being selected by WF for both;
– On an otherwise ‘quiet’ VPS, I’ve never noticed WF drawing attention to itself (resources-wise) for any other reason than scanning
– I guess it could any number of things causing the CPU spikes, not necessarily related to WF. If it always happened at the same time of day, that’s gotta tell you something (e.g. backups all running at the same time?)
– It depends on the rest of your server setup – I’ve certainly hit problems before with things like ‘sub-optimal’ configuration of php-fpm pools, resulting in more nginx/php services being spawned than necessary. But of course you might have a completely different setup.

My first response is always to try to understand the pattern of behaviour (time-wise) and then drill into the logs for those times for clues.

All of that said, I’m no expert by any means – but I do share your frustration.

Using a VPS is definitely going to be worthwhile in the end, it’s just the learning curve that’s the problem.

Assuming that you’ve got SSH/console access to the VPS, I find that a tool like ‘htop’ is really useful because you can see a live view of the processes and which ones are hitting the CPU. You’ll just find yourself sitting there staring at it though.

Aside from all that, I’m assuming that you don’t see spikes from ‘unwanted’ traffic at these times? e.g. if you look at the access logs, you’re not getting loads of hits to /wp-login.php or some other attempt to compromise the site? For sites that don’t require customer logins, I’ll always set the WF option for ‘immediately block invalid usernames’ because at least then each IP can only guess one username before it gets blocked. And set some sensible rate limiting rules too.