jrivett

It would really help if I knew what to tell them. From the perspective of your plugin, what is the significance of the messages? What is WPSSO trying to do that is causing it to show those messages?

The site works fine, as do the others hosted on that server. DNS also checks out. I disabled a couple of security plugins (BPS and Wordfence) but nothing changed. WPSSO seems to work okay, despite the messages. But I’d be happier if I knew what conditions are leading to the messages. Can you provide any background on what causes them to appear? For the record, the reported URLs actually work.

I used the Analyticator ‘Reset’ option. I had to re-enter an auth code, but it seems to have fixed the problem.

Two of my sites were actually affected. To fix them, I used the Analyticator ‘Reset’ option. I had to re-enter an auth code, but it seems to have fixed the problem.

I get this as well, on two sites that use Google Analyticator, but not on at least two other sites that use it. The two affected sites are on different servers.

Thanks for the update. I installed the new version of Wordfence but sadly the scans show the same behaviour as before, with each set of 100 files taking 10+ seconds to complete.

At this point I’m about 95% certain that the remaining problem is not Wordfence, and I’ll know for sure when I upgrade Linux on my server.

Regarding the missing log: should I try again to send a debug log, or perhaps send a portion of a log instead of the whole thing? It might contain information useful to your efforts.

That’s good news on the upcoming improvements for slow ‘files per second’. There’s no way to know if it will have any effect on my issue, but my fingers are crossed.

My own research into this problem led to similar discussions of the possible performance benefits of noatime and relatime. I haven’t yet tried changing anything, but I do see that my main filesystem mounts all either specify relatime or don’t specify any options, which means the default should be used, and for Ubuntu 12, that’s relatime.

Since I see the same high levels of jbd2 disk I/O when other disk intensive processes are running (eg. Clamav database updates), I think it’s probably safe to assume that the problem is the server, not Wordfence.

I’ll update this post if I learn anything new, or if subsequent Wordfence updates fix the problem, since it may be of some use to others.

Thanks for your help!

I sent that earlier log to you, as well as the log from a new debug scan, which completed this time, taking about two hours. Interestingly, despite having already demonstrated that changing “Maximum execution time for each scan stage” to 24 fixed the problem of scanning too many files, the new debug scan once again scanned too many files:
Scan Complete. Scanned 45268 files, 17 plugins, 5 themes, 5 pages, 0 comments and 44279 records in 1 hour 57 minutes 32 seconds.

So it looks like debug mode changes the conditions enough to trigger that weirdness. I’m hoping you find that useful in your own investigations.

One other thing I should mention. My tests show that in Wordfence scans run on sites hosted on a Dreamhost VPS, about 500 files per second are scanned. On my own server, where I theoretically should be getting better performance, about 10 files per second are scanned. That’s a huge difference, clearly.

I’m starting to suspect a problem with jbd2/sda1-8 on my server: when there’s a lot of disk I/O going on (including during Wordfence scans), jbd2/sda1-8 is doing 99% of that I/O.

I enabled debugging mode on one of the sites and ran a scan before the change to “Maximum execution time for each scan stage”. The detailed activity box stopped updating during the scan, and I eventually killed the scan as it was taking forever. Attempting to view the log in Wordfence showed a blank page. However, I emailed it to myself and that worked, or at least I now have a good sized chunk of that scan. Should I forward that email to [email protected], or run another scan (now that “Maximum execution time for each scan stage” has been adjusted) and send that?

Thanks for the information.

I checked for symlinks in the site files, and found none. So clearly that’s not the issue.

PHP has max_execution_time set globally to 30, and the sites in question had “Maximum execution time for each scan stage” set to blank. Which means Wordfence would have been using 15. I changed the setting to 24 (80% of 30) as requested, and YAY, it’s back to scanning the right number of files. Total scan times are now on the order of 15 minutes. Thanks!!

Still, the scanning does seem to take longer than it ought (basic on other people’s scan times), and it does still hammer my server’s poor hard drive, AND there’s no noticeable improvement in scan times or I/O activity in Wordfence 6.2. Should I perhaps report this separately?

Yup, that was it: Core Control.

I may have spoken too soon. The problem now appears to be the Core Control plugin. Just confirming that now.

Looks like Jetpack is the problem. BLC was working fine on another site, then I installed Jetpack and it stopped working. If I’m able to determine which part of Jetpack is causing the problem, I’ll post it here.

Also, I tried removing and reinstalling BLC, but it didn’t help.

I’ll let you know. Meanwhile, we’re switching to Jetpack.