Cache directory is enormous

On further research I found that the old files are cleaned up when I clear the cache manually. So my question is: What would cause the plugin to fail to run its own cleanup?

sounds like its specialized cron it adds to wp-cron list isn’t working on your end. When i check my list i see a quick cache garbage clean up that is run either one per hour or once per day (cant remember which).

Curious…are those old pages continuing to use those old cachce files even though when you check the bottom of the page the expiration date indeed shows it has expired?

It does sound like wp-cron. What would cause that to fail and how do I diagnose its health?

As for the old cache files, they’re gone now. Hitting the clear cache button gets rid of them. But I don’t want to have to do this manually.

On further research, I’ve noticed this problem on several other sites. This first one came to my attention because of the enormous size.

Oh forgot to mention that I still get notifications of new WP and plugin versions. So wp-cron is working, at lease some of the time.

Fascinating. I wonder if your problem is like the other fellow. Curious:

1. Are ALL files not re-caching (remaining old)? Or just a selection of them?

2. If only select files then is there a pattern such as query strings in their url?

I would like to verify that loopback requests are working on your server.

Try adding these 2 test files to your server and running the LoopbackTest-Call.php file from your browser:

LoopbackTest-Call.php:
Note: Replace {YOUR SITE HOST NAME HERE} shown in the code below with your actual host domain (e.g:www .mysite.com).

<?php
	$ch = curl_init();
	curl_setopt($ch, CURLOPT_URL, 'https://{YOUR SITE HOST NAME HERE}/LoopbackTest-Reply.php');
	curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
	$html = curl_exec($ch);
	echo "Loopback Response: ".$html;
?>

LoopbackTest-Reply.php:

<?php
	echo "SUCCESS!!";
?>

If successful you should see “Loopback Response: SUCCESS!!“. It’s important that you call the LoopbackTest-Call.php file from your browser and NOT the LoopbackTest-Reply.php file. Once we know loopback requests are working on your server then we can continue to pinpoint what is going on.

To answer the last question first, here is the result of the loopback test: Loopback Response: SUCCESS!! Loopback Requests Work!

So apparently it’s not that.

This issue came up in the context of moving sites from an old hosting provider to a new one. The time to do that is a function of size, and I noticed the sites using caching were disproportionately large. Right now only about half the sites are moved. But I have checked sites on both the old and the new server; both are exhibiting this problem. So we may be able to rule out some oddball setting on the server.

I’m not seeing a pattern in what’s in the old cache pages. I saw pages and posts, and something that looked like search results. One thing that seemed odd is that the URL I saw in the cache file is the WP ‘default’ form, not the permalink. I suspect that’s intentional, though.

One thing I did do today was to disable wp-cron and, instead, run it from a cron job every 10 minutes. Too soon to say if that made any difference.

HTH and makes sense.

FWIW, here is the cron record from the wp_options table in the database. As you can see there is an entry for garbage collection. Whether or not it’s formatted correctly, I have no idea:

a:5:{i:1351963068;a:1:{s:45:"ws_plugin__qcache_garbage_collector__schedule";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:3:{s:8:"schedule";s:6:"hourly";s:4:"args";a:0:{}s:8:"interval";i:3600;}}}i:1351990192;a:2:{s:17:"wp_update_plugins";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:3:{s:8:"schedule";s:10:"twicedaily";s:4:"args";a:0:{}s:8:"interval";i:43200;}}s:16:"wp_update_themes";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:3:{s:8:"schedule";s:10:"twicedaily";s:4:"args";a:0:{}s:8:"interval";i:43200;}}}i:1351990239;a:1:{s:16:"wp_version_check";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:3:{s:8:"schedule";s:10:"twicedaily";s:4:"args";a:0:{}s:8:"interval";i:43200;}}}i:1352045366;a:1:{s:19:"wp_scheduled_delete";a:1:{s:32:"40cd750bba9870f18aada2478b24840a";a:3:{s:8:"schedule";s:5:"daily";s:4:"args";a:0:{}s:8:"interval";i:86400;}}}s:7:"version";i:2;}

All looks good there.

Curious, you mentioned that the “default” url form was in the cache file and not the permalink. To be clear you are saying you see something like: “https://www.mysite.com/?p=999” instead of “https://www.mysite.com/my-post”?

Are you noticing it at the bottom of the cache file where it says This Quick Cache file was built for or are you seeing this default form at the very top of the cache file? If its at the top then that is normal; at the bottom would be odd (assuming permalink customizations are being used).

Yes, the ‘?p=999’ flavor. But you’re right, it’s at the top. The URL at the bottom is the permalink.

Toying with the idea of a cron job to do a brute force clearing of the cache every night. Would prefer a proper fix, but the cron job would at least keep the storage under control.

@dicknet … did you every find out why it seems to be ignoring your 3600 sec “cache expiration time” ?

I just did an experiment to clear my 19K (1.6GB or 3+ month’s worth) of old cached files:
A. Yesterday the “clear cache” button on the top admin bar never completed.
B: Using filezilla to delete the contents caused filezilla to hang (or I just gave up)
C: Just now, I changed the cache expiration time to 3601 and within seconds all stale cached files automagically disappeared. Yay!

Fortunately my failed attempts never broke anything but I had to do something, since all file management tasks (like backup) were starting to fail due to the sheer volume of obsolete files.

@websharks or @primothemes (developer, if you are still supporting this) … my intuition says that there should never be any cached files on my server disk older than the “cache expiration time”. If I’m wrong, what is the logic here?

No, unfortunately not. As a workaround, I put in a cron job to clean it out by brute force every night. Not a great solution, but it was the best I could come up with.