2

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

| improve this question | |
  • Did you find out which cid's populate cache_render table? If we don't know we can only speculate. – 4k4 May 20 '16 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 May 26 '16 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. – 4k4 May 26 '16 at 7:03
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.

| improve this answer | |
  • 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 May 20 '16 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 May 21 '16 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 May 21 '16 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 May 26 '16 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.

| improve this answer | |
  • 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 May 20 '16 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. – 4k4 May 20 '16 at 8:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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