Our proprietary cache system has a function which deletes a 
cache directory allowing for the files to be recreated.   
Subsequently this causes APC to rebuild its cache.  Before 
the 
release of APC 3.0.8, apache would stop responding when the 
application cache was cleared and would need to be 
restarted.

Currently, with APC 3.0.8 if the application cache is 
cleared, apache will 
not fail, however if for example, the application cache is 
cleared 3 times 
over a period of 20 min the final clear cache will cause 
apache to stop responding.  Before apache stops responding 
the 
APC info page shows significant fragmentation in its cache.  
Also at this point APC has uses up all of its allocated 
memory.

A couple of comments on this one.  

First, make sure you are updating these files in an atomic manner.  You can't just copy files into a live document_root or you will end up getting partial files served up, and with an opcode cache this means partial opcodes cached, which causes all sorts of badness.  So, things like tar, cp, scp are bad.  But mv and rsync are good.

Second, when doing a mass update like this, if the server is currently being hit hard, there will be a sudden rush to cache these new files.  You should consider enabling apc.slam_defense and perhaps also apc.file_update_protection.  These are documented at http://php.net/apc

No response for many months.  Assume problem (or user) has gone away.  Not enough to go on here anyway.  If it is still happening, try current CVS and reopen the report if you have more info on this.