3

I am having a drupal 8 website where cache_render table is growing to GBs. I am not sure why this growing huge, any starting pointers would be helpful.

Thanks

3
  • Did you find out which cid's populate cache_render table? If we don't know we can only speculate.
    – 4uk4
    Commented May 20, 2016 at 13:21
  • @4k4 I see all the cache entries with expiry as -1, they are set to never purge, looks weird and cache entries are mostly of different blocks, does it look like a core issue?
    – arpitr
    Commented May 26, 2016 at 6:38
  • 1
    If they are from cached pages (if the cid starts with http), then yes, this is a core issue. There is an ongoing discussion how to use max-age to set an expire time. If they are blocks, then no, this is normal. Most blocks have no cache setting with max-age and are stored permanently. You can add a max-age when building the block.The dynamic cache for blocks respects the max-age.
    – 4uk4
    Commented May 26, 2016 at 7:03

2 Answers 2

2

There are some ongoing improvements to e.g. cache 404 pages only for a short time.

Make sure that cron is running, so that expired caches are deleted.

Also consider using an alternative cache backend like Redis or Memcache, both have a max size that the allocate and delete items that have not been used for a while.

4
  • thanks @Berdir cron is working fine. I see a lot of page not found errors in dblog, I did a grep for the same in cache_render table output but did not found anything. I am on drupal 8.00 I am thinking to upgrade it might be there is a problem with perging with my drupal core. thanks again!
    – arpitr
    Commented May 20, 2016 at 11:19
  • 1
    Since Redis has not been ported to Drupal 8 yet, I guess Memcache is the only option for now.
    – No Sssweat
    Commented May 21, 2016 at 5:12
  • 1
    Except it is: drupal.org/node/2578085, github.com/md-systems/redis. We have been using it for more than a year now on production.
    – Berdir
    Commented May 21, 2016 at 8:04
  • @Berdir I see all the cache entries with expiry as -1, they are set to never purge, looks weird and cache entries are mostly of different blocks, does it look like a core issue?
    – arpitr
    Commented May 26, 2016 at 6:39
1

Did you inspect the content of the table cache_render? The page element that uses the most space will be obvious, because it has the most entries.

For example a block with a cache context on url.path:

cid:
entity_view:block:block_name:[languages:language_interface]=??:[url.path]=/aaa/bbb/ccc:[user.permissions]=???

The cache contexts are in square brackets [].

In this example you would get a new entry in the cache table for every page with a different url you visit which has this block on it.

In this case you could think about changing this to [url.path.parent] like the breadcrumb block does, this would reduce the amount of data.

2
  • Thanks for the answering, I am wondering if there is a way I can turn off caching as a quick fix and later figure out what causing the issue?
    – arpitr
    Commented May 20, 2016 at 7:36
  • 1
    That's difficult, because the cache backend can be used by many services in your drupal installation. And if you try to switch them off your performance will be very bad. But you can clear the cache, then you start again with 0 GB.
    – 4uk4
    Commented May 20, 2016 at 8:03

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.