Plugin Crashing Site by overloading DB

Wow – that is certainly something that I will fix. Could you provide a sample of the lines that are being written?

Certainly, here’s an example:

option_name

_wp_session_328a5b7fb88d1e05748298660cd9230a

option_value

{s:11:”wpex_viewed”;O:21:”Recursive_ArrayAccess”:2:{s:12:”*container”;a:0:{}s:8:”*dirty”;b:0;}s:14:”wpex_impressed”;O:21:”Recursive_ArrayAccess”:2:{s:12:”*container”;a:0:{}s:8:”*dirty”;b:0;}}

and it just goes on and on like this intermingled with _wp_session_expires lines that have values like 1413123894

Any help cleaning this up?

Hm – these rows are added by the session manager which keeps track of user’s sessions so that they are consistently shown the same titles. How many unique visitors does your site get daily?

We get about 2000 uniques a day.

I’ve updated the plugin to version 5.1. I don’t know for sure that this will solve the problem. I’ve reduced the lifetime of the sessions and upgraded the session manager to the newest version. Could you update and see if it resolves the problem?

I’d love to know if 5.1 has addressed your issue @gabernx

hope so ??

Since this post I’ve published a few more performance updates. It hasn’t resolved it yet for another user but I’m still working on trying to figure out where exactly the lag is coming from.

Update: We ended up uninstalling the plugin and deleting it. Everything was looking fine for a day or two but today it somehow CAME BACK! I have no idea how those tables returned but it immediately started crashing our server by writing MILLIONS of lines into the WP_options table. We are trying to work with our host to remove it somehow, but this is insane. It has ballooned the options table to over 1.5 GB and cause us a ton of grief.

?? I’m sorry to hear that. I understand. I’ve narrowed down the problem to how the plugin deals with sessions. It’s not a workable solution for high traffic sites. I know how to fix it but haven’t done it yet. I’ll be sure to update you when it is fixed.

Are you saying it worked for a few days after uninstalling it and then crashed again without my plugin installed? That doesn’t seem to make much sense. The fix for the cleaning out the bloat from my plugin is:

DELETE FROM wp_options WHERE option_name LIKE "_wp_session%";

Note: this will delete all the session records from the table. My plugin uses a library that other plugins may use as well so it could clear other sessions as well but since they are meant to be transient, it shouldn’t be a big deal.

I see, yeah that is the really bizarre thing. The plugin files are gone, but the database still got slammed by it. Not something I even knew was possible, and it happened on both our live and dev servers, with the plugin deleted on both…

Are you sure that those rows were created after the plugin was removed? If there were created afterwards, do they look like the ones that were around before (with wpex in the option_value)? Is it possible the plugin was still cached somehow?

Either way, I hope you can get your site humming again and I will let you know when I get the plugin operating correctly. Sorry about that!

Thank you, yeah that’s actually what Im suspecting after reviewing the logs. May have been a plugin called WP Cleanup Optimizer that has some DB upkeep cron jobs or caching set up that reinstated all those rows. Cleaned it out as well now and hopefully that should do it. Best of luck working out a high traffic solution!

Hi –

I’ve updated the plugin to 5.7 which removes the session library that was causing your troubles. I think it should fix your problem!

I have the exact same problem. Uninstalled the plugin a few months ago, but entered phpmyadmin yesterday and noticed 4 million rows caused by this plugin.

Has this problem been solved in the new version?