[Tickets #14258] Re: File based cache garbage collection broken

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: https://bugs.horde.org/ticket/14258
------------------------------------------------------------------------------
  Ticket             | 14258
  Updated By         | arjen+horde at de-korte.org
  Summary            | File based cache garbage collection broken
  Queue              | Horde Framework Packages
  Type               | Bug
  State              | Resolved
  Priority           | 2. Medium
  Milestone          | Horde_Cache 2.5.3
  Patch              |
  Owners             | Jan Schneider
------------------------------------------------------------------------------


arjen+horde at de-korte.org (2016-02-16 20:00) wrote:

> We didn't lock the GC index in the old version either, so this  
> couldn't be a reason for the regression. And we *do* lock the old  
> index file while doing the migration, so the migration couldn't  
> introduce this regression either.

The cache that broke things wasn't migrated. I started out with a new  
cache about a week ago, when reports came in that people saw huge  
increases in their caches. At that time I took the plunge, stopped  
PHP, cleared out the cache, changed sub from 1 to 3 and started PHP  
again. Initially all looked good, so what I saw today was not caused  
by doing a migration (as there was nothing to migrate).

> Do you even see this after wiping the cache completely? This  
> shouldn't be necessary of course, but with your current broken index  
> files, you would have to do this anyway.

I started out fresh again today with a new cache. For the record, the  
line lenght in the freshly created cache in /var/cache/horde/  
directory with sub=3 equals 74 characters.

The longest lines in the old cache that ran my Horde installation in  
the ground today was exactly 122304 bytes for the vast majority (>  
90%) of the horde_cache_gc files. This could be due to the fact that  
when things went south the load on the system was very high, due to  
the massive I/O that was taking place at the time and the chances of  
collisions were high.