Problems with APC fragmentation Drupal 6 sites

Events happening in the community are now at Drupal community events on www.drupal.org.
wxman's picture

Hi

I'm using the latest Drupal 6.x version for several sites on my server. I'm getting a lot of fragmentation after setting up APC, but I can't figure out why it's happening, and how to stop it.

I've read most of the discussions here, as well as Googling others. I increased the amount of apc.shm_size to 64, then backed it back off to 56, because it was getting fragmented so quickly. Now I can go just a few hours before it's back to 100% fragmentation. I'm using a core duo processor, 64 bit Ubuntu server, with 2.3Gb usable RAM.

Here is the info from apc.php:

From APC.PHP
------------------------
APC Version 3.0.19
PHP Version  5.2.4-2ubuntu5.9
Server Software    Apache/2
Shared Memory  1 Segment(s) with 56.0 MBytes (mmap memory, pthread mutex locking)
File Upload Support 1

Runtime Settings
apc.cache_by_default    1
apc.coredump_unmap    0
apc.enable_cli    0
apc.enabled   1
apc.file_update_protection    2
apc.filters  
apc.gc_ttl 3600
apc.include_once_override  0
apc.max_file_size 1M
apc.mmap_file_mask  
apc.num_files_hint 1000
apc.report_autofilter  0
apc.rfc1867   0
apc.rfc1867_freq  0
apc.rfc1867_name  APC_UPLOAD_PROGRESS
apc.rfc1867_prefix  upload_
apc.shm_segments    1
apc.shm_size  56
apc.slam_defense 0
apc.stat  1
apc.stat_ctime    0
apc.ttl   1300
apc.user_entries_hint  4096
apc.user_ttl   0
apc.write_lock    1

Doing a soft restart on Apache fixes the problem, but it always comes back. I even disabled PECL uploadprogress because I read that could cause problems. If anyone has had similar problems, and found the cause, I'd love it if they could point me in the right direction.
Thanks.

Comments

Are you using APC only as an

johsw's picture

Are you using APC only as an opcode cache or as a data cache as well?

Just as an opcode cache.

wxman's picture

Just as an opcode cache.

Double php.ini max memory

mikeytown2's picture

Whatever your max memory setting for PHP is; double it for APC. The odds of the cache fragmenting will be very low then.

Right now my php.ini is set

wxman's picture

Right now my php.ini is set at:
memory_limit = 128M
So I should set apc.shm_size to 256?

256 might be too much. Here

emcee0's picture

256 might be too much. Here are my settings that work very well for me with almost no fragmentation and 98% hit rate.

apc.enabled=1
apc.shm_segments=1
apc.optimization=0
apc.shm_size=128
apc.ttl=7200
apc.user_ttl=7200
apc.num_files_hint=1024
apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.enable_cli=1

How much RAM are you using?

wxman's picture

How much RAM are you using? My server is on a Xen virtual system, with around 2.3Gb available.

I'm on a 4GB dedicated system

emcee0's picture

I'm on a 4GB dedicated system and only using up 650 MB. The APC cache usage is around 65 MB out of the 128. Drupal's php scripts do not take up a ton of memory to cache. Btw, please do not turn off APC stat, if you make any changes to your php file, it will not update. It doesn't affect performance that much to turn on stat. If you paste my settings into your php.ini, I think you should be good.

Mod Uploadprogress has

bennos's picture

Mod Uploadprogress has nothing to do with APC. It is a different PECL module. APC has an own upload progress Module (apc.rfc1867 = 0). the APC upload is buggy. there are several bugs in the php apc issue queue.

apc.rfc1867 = 0 means the Upload module by APC is off.

Your Fragmentation should come from

apc.stat =1

Apc checks on every request, scripts are changed or not and will recompile it. Not Good.

So should I try apc.stat =0?

wxman's picture

So should I try apc.stat =0?
Isn't that taking a chance when scripts are updated?

see this article, why

bennos's picture

see this article, why apc.stat should be = 0 and the shm higher then 48M

http://2bits.com/articles/high-php-execution-times-drupal-and-tuning-apc...

My Jobs Exchange:

Job Ingolstadt

Fragmentation happens when

smk-ka's picture

Fragmentation happens when memory blocks are released. Thus, to completely avoid fragmentation you have to disable the time-to-live (TTL) of cached scripts. You can do this by setting apc.ttl=0. However, this means that with every PHP script executed the cache will grow, and never release the memory. Alternatively, to avoid the fragmentation happen so quickly you could also try to simply increase the TTL, for example by setting apc.ttl=86400. This will release memory if a script hasn't been accessed for more than 24 hours.

-Stefan

For now I'm going to try

wxman's picture

For now I'm going to try emcee0's advice, and see how that works. I'l be using /etc/php5/conf.d/apc.ini to do the edits instead of php.ini.

I turned the upload progress back on in my php.ini - thank you bennos, I didn't notice the difference before.

I'll be back if the server crashes again.

NOTE: I wish I could upgrade the version of APC, because that might help. The Ubuntu version is at 3.0.19.

Beware of conf.d/apc.ini

fgm's picture

Its parameters are shared by all SAPIs, whereas you typically do NOT want the same parameters on CLI at Apache2. Most of the time, you don't even want APC on CLI, so it is normally a better choice to set up APC only in apache2/php.ini instead of conf.d/apc.ini

Good point. I'm not using

wxman's picture

Good point. I'm not using CLI, but I could see where that would make a difference.

3.0.19 is what I'm using.

emcee0's picture

3.0.19 is what I'm using. It's the latest stable release. Everything higher is in beta.

So far so good with the new

wxman's picture

So far so good with the new settings. I'll give it a few hours to see what happens.
I'm trying to get the system running at it's best now before I turn on all the Drupal sites. I have only three running now, along with a couple of regular ones. We have two or three more Drupal ones to add, and five or six regulars one as well.
I had posted here once before (http://groups.drupal.org/node/37266), after I had a major meltdown, that led to me installing APC. I never got any responses to that posting, so I'm glad I got some help on this one. I think this group is very important to help people like me in getting the most out of Drupal. I hope someday I can help others here as well.

I checked it this morning,

wxman's picture

I checked it this morning, and it's better. It's showing 99.9% hits, .1% misses, and 9.88% fragmentation. If that's as good as I'm going to get it, I guess it's better than 100% fragmentation after just a few hours.

It figures that it was too

wxman's picture

It figures that it was too good to last. I'm seeing 100% fragmentation again at least once a day. It seems to go away after a while, I'm guessing when the timer removes the offending files.

Did you use the chunk of

emcee0's picture

Did you use the chunk of configuration in the apc.ini? Or did you include it with other settings? Do you have apc.stat set to 1?

apc.stat is set to 1. I'm not

wxman's picture

apc.stat is set to 1. I'm not sure what you mean by the other question. Sorry.

High performance

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week