Table "ibf_core_output_cache" over 100GB. Server slows down

[tolik777]

After upgrading to versions 4.3 to 4.4.x, I had periodic problems with the ibf_core_output_cache table. Everything worked fine for 2-3 months, then this table began to increase dramatically and the server was terribly slow because of it, because there were many requests to HDD and it did not have time.
I cleaned the table ibf_core_output_cache, started reindexing and everything was fine for a few months again. Then everything again.

This Sunday I upgraded to the new version 4.6.8 (from 4.4.x). Everything updated fine, re-indexing ended yesterday. But now I see that ibf_core_output_cache is growing again, and noticeably faster than before. If in the morning the table took 77 GB, only a few hours later it takes almost 100 GB. So +20 GB in just a few hours!
The site begins to slow down again, CPU load reaches an average of 20-30%. Although usually the average value is 5-10%.
I hoped that in version 4.6.8. they will fix the problem with ibf_core_output_cache, but the problem stays the same.
I use Redis on my server and have it enabled in the settings, but it doesn't help in any way.

 

[Marc]

Please update your access details on file, and we can then take a look for you. Also please disable redis while we take a look. In all honesty, if you have enabled this to solve the issue here, I would advise on not doing this.

[tolik777]

I'll try to disable Redis, clear ibf_core_output_cache and start reindexing.
I guess that old entries in this table should be cleared after a period of time? If yes, how often should it happen? How does cleaning happen at all?

[Marc]

They will be rebuilt, but it will not clear entirely. This is done on task which runs every 10 mins, provided your tasks are running properly

[tolik777]

I manualy cleared it "truncate ibf_core_output_cache" via mysql console

[Marc]

23 minutes ago, tolik777 said:

I manualy cleared it "truncate ibf_core_output_cache" via mysql console

I would advise against doing that. All that will happen is it will grow again if the issue is still present. We need to gain access when its in that state in order to ascertain the issue.

The likelihood is, its actually the MySQL instance that isn't releasing space, but there is no way of knowing this now its been truncated unfortunately.

[Marc]

Did you manage to get that resolved?