Donncha O Caoimh (a11n)

Since you have WP Control installed, and you can see wp_cache_gc show up there in “Cron Events”, set the GC Timer to 60 seconds and keep reloading the WP Control cron events pages to see if wp_cache_gc triggers. Is it scheduled again afterwards?

I suspect some other plugin updated and is causing problems. You might also check your PHP error logs. If another plugin is causing a fatal error when it runs a Cron job, it might be stopping the garbage collection from running. You could also disable other plugins one-by-one, and then go to WP Control and click on “run now” under the wp_cache_gc job. That might help track down the problem.

You might need to contact your hosting support to get this fixed. Someone with access to your site will probably be able to fix this quickly.

Can you respond to my question: ‘wp_cache_gc’ scheduling is set to “Do Not Repeat” — Is this correct?

Yeah, that’s fine. The garbage collection system schedules the next job after it’s finished the current one.

Is the cache directory still 500MB, or has it rapidly increased in size?

When you go into the cache directory, are there thousands of files, or about the same number of files to the number of pages on your site? Do the directories they’re in match those pages? Do the cached html files look inflated by anything or do they match the size of pages on your site?

500MB seems a lot, especially if the GC is working and clearing out files that are older than an hour. If you check the “Email me when the garbage collection runs” checkbox, the site should send you an email every ten minutes saying it’s working. That might be worth doing for a small bit to make sure it’s ok.

If there are thousands of files, can you see if any are older than an hour? A few minutes over an hour is ok, but if there are files that are a few hours old then garbage collection isn’t working.

@squire2k – I tried to replicate the problem again, and it appears to be fixed. I still see the problem on your site, however, so can you make sure you update your plugins and WordPress?

Hi,

Are you disabling caching when a cookie is detected? Set it to “Enable caching for all visitors” (or the last one, to disable it for logged in visitors only) instead. If the cache is disabled by the wp-discuz plugin, you should talk to the author of that plugin and show them this thread. They can add support for WP Super Cache using the following code.

You need to tell WP Super Cache to use those cookies to identify users because it only uses the default WordPress cookies by default. Read this page to learn more, but you should add the following lines to an mu-plugin file:

do_action( 'wpsc_add_cookie', 'comment_author_email_{HASH}' );
do_action( 'wpsc_add_cookie', 'comment_author_{HASH}' );
do_action( 'wpsc_add_cookie', 'comment_author_url_{HASH}' );

Replace the HASH at the end with whatever it is on your site, and test it. It should create a new cache file when you leave a comment.

Donncha

Is the garbage collection still set to 3600/600? Can you manually clear out the cache, and check the cache directory to make sure everything (or at least, most of everything) was deleted.

Then wait 60-70 minutes and look in the cache directory again and check if things were deleted.

If, after only an hour, the contents of the directory is huge again, it might be worth changing the garbage collection to 600/60 or maybe even 300/60 so files are deleted more quickly.

If it looks like no files have been deleted, it might be a problem with PHP deleting so many files and timing out. 7034MB of files is excessive, if your GC is set to 3600/600. Reducing the time limit should help there.

When you look at the files generated in the cache directories, are they index-https.html and maybe index-https.html.gz ? Or do they have a long random string of letters?

You could also enable debugging in the plugin and visit the site in a private browser and look at the logs to see if they show you any problems.

• This reply was modified 2 weeks, 1 day ago by Donncha O Caoimh (a11n).

I’ve just created a ticket to track updates on this problem. Find it here: https://github.com/Automattic/jetpack/issues/39971

OK, this PR should fix things. I’d appreciate it if you could test it: https://github.com/Automattic/jetpack/pull/39951

Does the drop-in apache_request_headers() function work well for you?

To avoid problems I’ll add a “wpsc_” to the function name and put the is_callable() check inside there. The PHP docs have more complicated fallback functions in the comments, but I’d rather not replace that part of the code if it’s working.

Hi,

This plugin caches the HTML pages sent by your server to your browser. WordPress itself adds the lazy loading tags required by modern browsers, so if they’re added to your images, the tags will be cached by WP Super Cache as part of the page.

It doesn’t define the cache policy for static assets, either. However, if you install Jetpack Boost, that will allow your site to use a CDN and offload serving images to another server.

Donncha

Hi @elevated420,

There’s a good reason why the theme says caching should be turned off “while developing”. It’s because you’re probably changing PHP files in a text editor. There’s no way for a caching plugin to know that the file was updated. With caching disabled, you’ll see any changes immediately.

However, when you’ve finished the main work on your site, then enable caching. If you need to tinker with your theme by editing PHP files, then clear the cache, or “disable caching for logged in users” on the settings page. You’ll see changes immediately, and you can clear the cache when you’re finished, so other visitors to the site then see the changes.

@ericr23 That attack was probably it. Tá áthas orm go bhfuir tú amach cad a bhí cearr ann. (“I’m glad you found out what was causing it”, for anyone else reading)

Fáilte romhat!

Sorry for not getting back to you sooner. That’s really strange. It might be worth looking at what sort of files are in your cache. While there is a “Contents” page in the plugin, it will be faster if use some sort of file manager or sftp client to examine what’s in wp-content/cache/supercache/ and it’s sub directories.

Maybe some plugin on your site has created an infinite loop, which Google or some other bot keeps downloading, and then the plugin caches those pages.

The other thing to do, is make sure that the cleanup job is scheduled correctly. Download the WP Control plugin. Go to Tools->Cron Events in wp-admin. Search for the string “wp_cache_gc” and if it’s working properly it will tell you that it will run in the next hour.

If it’s not running, and there are no errors showing, deactivate WP Super Cache and then reactivate it, and save the garbage collection settings on the settings page, just to make sure it’s set up again. Check the Cron Events page again. Hopefully it’ll be there this time.

Thanks @dominikshaim. I’ll test that out.

That’s not good, but it’s not a bug in the plugin. The first line mentioned checks if a directory exists, and the second gets the “realpath” of a directory.

Do you have a very flat URL structure? Without dates in the URL? Did you change garbage collection to make it store more cache files? If you do have a flat URL structure but didn’t change GC settings, your site might just have more traffic and is storing cache files. It might simply be bots visiting the pages of your site.

Either there are far too many files in that cache directory, or there’s something wrong with your web server’s filesystem, and the filesystem needs to be repaired. Did your server get turned off suddenly recently?

That’s almost right. Make the first one 3600. Change the second option back to the “How often to check for stale cached files” and make it 600.

Or make both smaller, but the second figure should be smaller than the first one by a large margin, so it checks more often for stale files.