We are using just drupal_flush_all_caches() (which is an equivalent of drush cc all), to get rid of any garbage accumulated before doing db dump (and sed based filtering on the fly), while drupal_flush_all_caches(), despite its name, purges only some core bins and explicitly excludes cache_form bin.

The problem is that cache_form bin easily grows out of control (like 500 MB or more) and as a result, not only slows down any task involving backup (db dump) but also easily and silently (!) breaks such tasks, with no helpful debug message, because we proceed even if the db dump effectively failed and there is no backup for further actions, like clone or migrate.

We have seen this too many times and finally determined it was always a result of having cache_form bin full of accumulated garbage.

Now the question is: should we add only:

cache_clear_all('*', 'cache_form', TRUE);

or maybe nuke all existing cache bins?

Comments

anarcat’s picture

Status: Active » Closed (won't fix)

hum... i was thinking we should move more in the direction of doing *less* cache clear because of the performance impact of such jobs on big sites. basically, i think we should split cache clear in a separate task so it can be more clearly controled.

see also #1484214: [meta] migrate/clone performance optimizations and #2088761: Do not verify after clone.

omega8cc’s picture

I know that older issues you linked, of course, but I don't think that avoiding clearing caches will help in anything here. Yes, it puts an extra load on the system, but how you imagine to avoid this? If you *skip* cache tables during db backup, you are effectively purging them, right? You are going nuclear then. And if you don't do that, you waste resources on dumping and importing tons of garbage, which, as this particular issue shows, adds more load and *easily breaks* clone and migrate tasks. Sure, we should avoid *unnecessary* cache clears or db updates, but the clone and migrate tasks are not candidates for such "optimization".