I was recently asked to investigate a warning about low disk space because of the database growing. The culprit turned out to be the cache_form
table, which apparently had reached close to a couple of GBs in size. Turns out that this is a known/common problem:
cache_form is never cleared on some sites (D7 core issue, reported in March 2012, still open at the time of writing)
https://drupal.stackexchange.com/questions/69803/cache-form-table-size-i...
The
cache_form
table is a little funny, and behaves in a slightly different manner than other cache tables.If you take a look at
drupal_flush_all_caches()
you will see thatcache_form
isn't cleared. This is to protect in-progress forms from being nuked.The
system_cron()
function does take care of pruning out old data fromcache_form
along with the other cache tables.You really should run cron on all Drupal sites...
In my case, cron was running just fine. The cache_form
table was simply not being cleared, and it had reached 9000+ rows. It was just spambots
While troubleshooting, I had to "manually" fix things by truncating the cache_form
table (ssh -> mysql commands and queries etc.). This seems to be a far too common problem for us to ignore. We should be providing the common Joe with the tools to perform cleanup via the UI.
Here's a few thoughts/suggestions:
- Provide a way to see db tables sorted by size in the admin UI (site status page, db info section)
- Allow truncating the
cache_form
table via a dedicated "Flash form caches" submenu, under the admin menu "Flash all caches" ("Flash all caches" is left as is though, still excluding thecache_form
). - Add a new "Clear form caches" button in
/admin/config/development/performance
. Make it adanger
/red button, have help text explaining why. - Ensure that both the admin menu item and the button in the performance page have a confirmation dialog.
drush
command
Here's a D7 contrib module that does most of these things: https://www.drupal.org/project/optimizedb
There is well-known issue with fast-growing table cache_form. This table stores Drupal form cache and it isn’t cleared when you flush all cache or run cron. Also you can struggle with problem of fragmentation with InnoDB tables on active delete/insert operations. This module provide functionality to solve this problem. Also its provide additional tools for maintenance database.
...this module seems to have originated by https://www.drupal.org/project/db_cache_clear
The project is originated by issues #2382227: Add option to clear cache_form expired records and #2409377: Add option to clear all cache tables using 1 button and by cron
Update: Module OptimizeDB should solve the above issues.
Perhaps related: * https://github.com/backdrop/backdrop-issues/issues/1470 [PS] Use signatures instead of the form cache * https://github.com/backdrop/backdrop-issues/issues/3833 [PS] Do not make entries in "cache_form" when viewing forms that use #ajax['callback']
Recent comments
Hello @NumerousHats, I agree with your assessment. I am looking into this situation right now. The root of this problem is that Backdrop CMS is implemented on top of a "stack" of...
Update Core and Theme via Web interface
I just installed a Backdrop CMS site with version 1.27.0. I then used the user interface to download and update Backdrop CMS to 1.30.0. After starting the update process, and on the...
1.30.0 update.php generates incorrect link
I believe my permissions are set up correctly, as I can install modules from the UI. But for whatever reason, I can't update them. I will, however, double check against that documentation.
Update Core and Theme via Web interface