Re: APC timeout question?

On Mon, 26 Jul 2004, Shannon Werb wrote: > Curious if the configure parameter, apc.gc_ttl: > > apc.gc_ttl The number of seconds that a cache entry may > remain on the garbage-collection list. This > value > provides a failsafe in the event that a server > process dies while executing a cached source > file; > if that source file is modified, the memory > allocated for the old version will not be > reclaimed until this TTL reached. Set to zero to > disable this feature. > (Default: 3600) > > Will allow me to set the amount of time a file is cached without being hit > before it is purged from the list? I think this functionality used to exist > in a past version under apc.ttl? > > I would like to have APC free the memory and cache for any pages that have > not been hit in so long, is this possible? If you look at apc_cache.c you will see that apc_cache_insert() calls process_pending_removals() which looks like this: static void process_pending_removals(apc_cache_t* cache) { slot_t** slot; time_t now; /* This function scans the list of removed cache entries and deletes any * entry whose reference count is zero (indicating that it is no longer * being executed) or that has been on the pending list for more than * cache->gc_ttl seconds (we issue a warning in the latter case). */ if (!cache->header->deleted_list) return; slot = &cache->header->deleted_list; now = time(0); while (*slot != NULL) { int gc_sec = cache->gc_ttl ? (now - (*slot)->deletion_time) : 0; if ((*slot)->value->ref_count <= 0 || gc_sec > cache->gc_ttl) { slot_t* dead = *slot; if (dead->value->ref_count > 0) apc_log(APC_WARNING, "GC cache entry '%s' (dev=%d ino=%d) " "was on gc-list for %d seconds", dead->value->filename, dead->key.device, dead->key.inode, gc_sec); *slot = dead->next; free_slot(dead); } else { slot = &(*slot)->next; } } } So yes, setting ap.gc_ttl will dictate how long stuff will stick around on the deleted_list, but things only end up on the deleted_list when they are actively removed through a call to remove_slot(). This only happens when the same inode gets a modified set of opcodes. So simply having scripts sitting around that don't get hit often will not cause their cached opcodes to get timed out. I agree with you that this would be a nice thing to have. -Rasmus