No one??
Well that’s OK. After some research, it looks like transients expire (delete) when you try to retrieve the same exact transient. If a plugin never tries to retrieve the same transient, it will never get deleted.
The problem I’m experiencing is that the plugin I’m using is naming the transient with an MD5 hash of a URL that contains about 10 different GET variables which are generated by 10 text fields. So this means that it’s rare for visitors to enter the same exact data, which means the transients are never getting called again. Thus the 2GB large table.
Perhaps WordPress needs a garbage collector of some sort for transients…
I had the same problem, so I made a plugin which can be found at this address: https://github.com/Seebz/Snippets/tree/master/Wordpress/plugins/purge-transients
Seebz, thanks so much for this plugin. It’s saved my site. I had a wp_options table that was a whopping 5.1 GB and kept crashing my site. I reduced it to 188 KB by cleaning out all the transient crap that wasn’t expiring and caused my site to run out of memory (I also had to use Clean Options to get rid of a ton of jetpack_nonce entries that also weren’t expiring, but that’s another matter).
Unfortunately, about 12 hours after reducing it to 188 KB, the table was back up to 500 MB, which led me to the purge-transients plugin. It’s kept my site online but I’d like to get to the root cause.
Do either of you know which plugin/s were causing your wp_options to fill with these unique transients? I’m doing some troubleshooting of my own, and I’ll report back here if I find anything, but it would save me time if you already know what caused the rogue entries.
For the record, my entries seem to follow one of four formats (I think the IP addresses are from visitors, as they don’t correspond with my own):
transient_DIFFERENT.IP.ADDRESSbookmark
transient_timeout_DIFFERENT.IP.ADDRESSbookmark
transient_DIFFERENT.IP.ADDRESSsearch
transient_timeout_DIFFERENT.IP.ADDRESSsearch
