I use Drupal 6 with the Cache Backport module, and all the available cache tables are configured to be stored in Redis (similar to Memcached in function for RAM caching). The caching works very well.

I have noticed that the amount of data stored in Redis gradually grows as the cache warms up, which is expected. However, the amount of stored data regularly drops suddenly to almost nothing.

I ran a test by loading up the cache by running a search for the word "the". Usually the amount of data stored in Redis will climb to between 20 and 40 MB on that query. Then, I ran the filter_cron job (I use the Ultimate Cron module and can run the different cron jobs selectively.) The Redis memory immediately dropped to almost nothing. After loading up the cache again to 20 - 40 MB, I ran the system_cron, which instantly resulted in Redis memory dropping even lower than it did on filter_cron. Both of these results are repeatable every time. So obviously both of the system and the filter cron jobs are indiscriminately flushing the Redis cache, which negates the purpose of a cache.

Can I prevent cron jobs from flushing the Redis cache, and if so, how? Is there not effective intelligent cache expiration logic on an individual key basis? Or would the cache system malfunction if I prevented it from being completely flushed by the cron job?

Thanks a lot for the help!

1 Answer 1


The cache is flushed by the system_cron() module, so basically the only way to stop it happening is to hack the core system module (very bad), or use something like Elysia Cron to schedule that particular cron job to run on a slower schedule. One of the module's features is:

Set the timings and frequencies of each cron task (you can run some jobs every day at a specified hour, other only monthly and so on...). For each task you can simply choose between some frequently used options ("once a day", "once a month" ...), or use a powerful "linux crontab"-like syntax to set the accurate timings. You can even define your frequently used options to speed up site configuration.

It's worth bearing in mind that system_cron() performs some other tasks as well (cleaning up deleted files, clearing the queue and batch tables, etc.), so using this method will slow down those tasks too.

Although it's a bit long winded, and not very future-proof, perhaps the only way to get to a satisfactory solution would be to implement a cron hook in your own module, which performs the tasks of system_cron() minus the cache flush. Then you can schedule the system_cron() to run on a slower schedule that suits your caching needs.

  • Thanks a lot for the reply. And do you know if the cache system will continue to perform in a sane manner using its own expiration logic? Or will it start serving up stale results?
    – rahim123
    Commented Dec 28, 2012 at 13:42
  • I thought when cache_clear_all() gets called from system_cron(), just the expired entries are deleted b/c the first parameter is NULL.
    – mpdonadio
    Commented Dec 28, 2012 at 14:20
  • Yes, that's what this says here, but it's clearly expiring everything, at least with my setup.
    – rahim123
    Commented Dec 30, 2012 at 3:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.