Chris

So turning off the automatic scans fixed the problem, no excessive memory usage now. I was pretty sure that was the case, just wanted to give it enough time in case something popped up (even though it was daily).

It’s not the solution I was looking for though. I’d like to keep automatic scan going. Any ideas from the logs I sent in?

Also, any confirmation on how many queries to expect? I checked another site and saw 1000’s of queries but only about 40MB of memory usage. Otherwise I’m going to assume that 1000’s of database queries is normal. Now if we can just figure out why it’s using so much memory on certain sites.

Ok, I just sent the diagnostics report.

I disabled the scans and will see if there is still a problem or if it goes away.

I think the 1000s of queries might be normal and just logging which files have already been scanned during the current scan. It’s a little excessive and could probably be optimized some way, but if it’s running a query for every file and you have a bunch of plugins (1000s of files) then it seems like this would not be unexpected. (The unexpected part would just be the high memory usage.)

Ok, I changed the location and everything still looks good. I can’t say for sure if that solves the problem until the plugin is updated again.

I updated to 3.4.0 and the same thing happened – and saving the settings again fixed it.

I forgot I was going to turn on developer tools and see if it just wasn’t getting loaded or if it was trying and failing, or any other info I can get for you. On the next update I’ll try to remember and will post back what I find.

Hi Robin, thanks for the quick response!

1. Not the standard automatic updates as configured in the wp-config or by GoDaddy, but I do use InfiniteWP to manage multiple sites and I review and update plugins on a weekly basis. Was there an update last week from 3.3.9?

2. The current version is 3.3.10, and I do see that there is an update for 3.4.0 but have not installed it yet.

Any thoughts?

1. Filesystem, MySQL, PHP and Connectivity all have green check marks next to everything.
2. All of the cron job have a future date.

I enabled debugging mode and ran another scan. Near the end, I got the first email notification and looked at the log and saw Scanning contents… and two more emails and the end of the scan within about 30 seconds (I imagine there’s a slight delay on email delivery though but I don’t know how much).

Email 1 – 10:33:43 -0800 (PST)
WordPress peak memory usage: 548.83 MB
Number of database queries: 13944

Email 2 – 10:33:52 -0800 (PST)
WordPress peak memory usage: 420.74 MB
Number of database queries: 10400

Email 3 – 10:34:06 -0800 (PST)
WordPress peak memory usage: 359.51 MB
Number of database queries: 9393

I emailed the activity log to [email protected]. The domain is DramaInPanama.com.

Well that doesn’t really work. I deleted the tables, but they weren’t recreated. All of the settings were empty, nothing checked, and it wouldn’t Save Options without filling out some settings. So I deleted the wflogs folder too and deactivated and reactivated the plugin, so it’s back to defaults again, then I disabled Live Traffic View and a couple of alerts – no other changes.

But that didn’t fix it either.

Also, previously I was waiting for the regular scans, but I tried a manual scan just now and it triggered whatever is happening. So it’s definitely happening when the scans run.

Sorry for the delay, just busy and it’s a pain to get the logs. That didn’t work though – I was really hoping a reset would do it too.

So here’s what I gathered from one of the occurences…

…about 8000 queries exactly like this…

2315 Query SELECT name, val, autoload FROM ep_wp_wfConfig WHERE name = 'wfKillRequested'

…followed by about 13000 queries similar to…

2315 Query	INSERT INTO ep_wp_wfConfig (name, val, autoload) values ('scanFileProcessing', 'a:2:{i:0;s:104:\"wp-content/plugins/[...]\";i:1;i:1479507968;}', 'yes') ON DUPLICATE KEY UPDATE val = 'a:2:{i:0;s:104:\"wp-content/plugins/[...]\";i:1;i:1479507968;}', autoload = 'yes'

2315 Query	insert into ep_wp_wfFileMods (filename, filenameMD5, knownFile, oldMD5, newMD5) values ('wp-content/plugins/[...]', unhex(md5('wp-content/plugins/[...]')), 1, '', unhex('FB4F60D443ED475226B2B5950A0E0273')) ON DUPLICATE KEY UPDATE newMD5=unhex('FB4F60D443ED475226B2B5950A0E0273'), knownFile=1

2315 Query	INSERT INTO ep_wp_wfConfig (name, val, autoload) values ('scanFileProcessing', '', 'yes') ON DUPLICATE KEY UPDATE val = '', autoload = 'yes'

2315 Query	SELECT name, val, autoload FROM ep_wp_wfConfig WHERE name = 'wfKillRequested'

…all plugin files, plus a few at the beginning for wordpress core files…

…and ending with one really large query…

2315 Execute UPDATE ep_wp_wfConfig SET '...[BINARY?]

Thoughts? Ideas?

Ok thanks, I’ll try that.

I can’t repair the table, it was an InnoDB table. Check, Analyze, and Optimize all say it was OK.

Settings could still be changed, so I disabled the Firewall, deactivated the plugin (didn’t think about the “delete tables and data” setting), deleted all wf tables, deleted the wflogs folder in the wp-content follder, and reinstalled the plugin.

I’ll continue monitoring things and see if there are still problems, should know by tomorrow.

Yes, I read the other thread and figured I would include everything you had asked for.

Thanks for the quick response! I have submitted the question in the contact form.

My issue is that the “not_found” slug just loads WordPress’s 404 page, which loads all of the theme and plugin resources, which I’d like to cut out to reduce resource usage during attacks.

Thanks for getting back to me Gerroald, but that doesn’t seem right. The “Redirection Slug” would be the part of the URL after the WordPress URL that determines what page to load, and defaults to “not_found”.

Okay, I think I just got confused between features for a moment. It would be nice though if we could send them to a similar “error” page instead of redirecting them to a custom url/slug.

I guess one solution would be for me to create my own simple error page (like the one for lockouts), load it into the root folder and put that file name in the slug area. Not sure if that would work but I might give it a try.

• This reply was modified 8 years, 6 months ago by Chris. Reason: Gotta give my thanks first

Ah, thanks Michael, good to know.

@e2robert: I know this is an old post, but your the only one who’s posted a possible solution. Is that all the code that is needed? If so, as much as I don’t want to edit the plugin code, I think I can manage a change like that. Can you confirm if you tried the code you posted and if the plugin still functioned properly? Otherwise I may just have to try it myself and see how it turns out.