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

* Your Email Address
* Spam protection	Enter the letters below: . ,.__ . ._.. . \./ [__)\| \| \|\ \| \| \| \\|____\|_\| \\|
Comment	>> 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.
Attachment
Watch this ticket

Saved Queries