APC Fragmentation Issue

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
Lloyd's picture

I've been trying to tweak APC. Right now I'm dealing with some fragmentation issues. They creep up over time to above 10-15%. Then APC restarts (not sure why). I've attached a copy of the apc.php results if anybody has any suggestions.

Thanks

AttachmentSize
apc.php.pdf69.75 KB

Comments

Are you using APC as an

greggles's picture

Are you using APC as an opcode cache or a variable cache (or both)?

From that pdf he's using

brianmercer's picture

From that pdf he's using both; 15MB in user and 170MB in opcode.

How is that 170MB in code structured? Do you have several CMSes? Three hundred modules? Separate Drupal installs that don't share a code base?

Yeah I realize the size of

Lloyd's picture

Yeah I realize the size of APC is pretty large. I'm running several instances of Drupal (with the largest one running about 125 modules plus the drupal core required modules) not sharing a code base and one instance of Word Press. I have CacheRouter installed and configured for APC.

I'd be okay exluding a couple of the sites from APC if that were possible, as well as the Word Press site. Not sure how to do that though. Or if there's simply a better alternative.

Also, boost.module is in the APC cache and is huge. I am running Boost along with APC. Not sure if I should exclude boost from APC and if so how I would do that.

You could try using memcached

brianmercer's picture

You could try using memcached instead of APC for the data cache. That's not a terrific solution because of added complexity, but many people do go that route to separate out the data cache from the opcode cache.

It looks like right now you're using mmap instead of shared memory. How are you running Apache: pre-fork/mod_php or worker/fcgi? How are you set for memory?

It's possible to exclude items from the cache, but as greggles infers, it's probably the user data that's fragmenting and not the code. If you want to experiment, you can exclude from the cache based on the strings in the file path. Example:

apc.cache_by_default=1
apc.filters="-wordpress,-phpmyadmin,-www.example.com"

So if those words appear in the file's path, that file will not be cached.

Or you can do it the other way and include paths explicitly:

apc.cache_by_default=0
apc.filters="+pressflow,+drupal,+modules6,+libraries,+default"

When you install Boost it disables the cache_page table, i.e. at /admin/settings/performance Caching Mode:disabled. If that is set to disabled, then you're not caching full pages in the cache_page table and it's not storing pages in the APC cache. Boost stores its own cached pages as files on disk.

If at all possible you should

catch's picture

If at all possible you should try to set the Drupal sites up as a multisite install - you may only be able to share core, but that's going to be a lot of space in APC freed up for opcode even with just that.

Files Dir

mikeytown2's picture

Have yet to try it my self but you can use http://drupal.org/project/file_maintenance to move the files dir from sites/default/files to sites/example.com/files. Should make migrating to a multisite install that much easier.

Lloyd, have you considered

ron_s's picture

Lloyd, have you considered using Varnish rather than Boost? You'll get better performance and would be able to run it for each of your Drupal sites and the WordPress site.

Also you would have the option to run it as a file-based caching or as memory-based caching. Most people seem to run it as a memory-based cache because they receive better overall performance. Doing so would allow you to remove the APC caching of Boost.