1

I am setting up APC (v 3.1.9) on a high-traffic WordPress installation on CentOS 6.0 64 bit.

I have figured out many of the quirks with APC, but something is still not quite right. No matter what settings I change, APC never actually caches more than 32MB. I'm trying to bump it up to 256 MB. 32MB is a default amount for apc.shm_size, so I am wondering if it's stuck there somehow.

I have run the following

echo '2147483648' > /proc/sys/kernel/shmmax

to increase my system's shared memory to 2G (half of my 4G box). Then ran

ipcs -lm

which returns

------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 2097152
max total shared memory (kbytes) = 8388608
min seg size (bytes) = 1

Also made a change in

/etc/sysctl.conf

then ran

sysctl -p

to make the settings stick on the server. Rebooted, too, for good measure.

In my APC settings, I have mmap enabled (which happens by default in recent versions of APC). php.ini looks like:

apc.stat=0
apc.shm_size="256M"
apc.max_file_size="10M"
apc.mmap_file_mask="/tmp/apc.XXXXXX"
apc.ttl="7200"

I am aware that mmap mode will ignore references to apc.shm_segments, so I have left it out with default 1.

phpinfo() indicates the following about APC:

Version     3.1.9
APC Debugging   Disabled
MMAP Support    Enabled
MMAP File Mask  /tmp/apc.bPS7rB
Locking type    pthread mutex Locks
Serialization Support   php
Revision    $Revision: 308812 $
Build Date  Oct 11 2011 22:55:02

Directive   Local Value 
apc.cache_by_default    On  
apc.canonicalize    O
apc.coredump_unmap  Off 
apc.enable_cli  Off 
apc.enabled On  On
apc.file_md5    Off 
apc.file_update_protection  2   
apc.filters no value    
apc.gc_ttl  3600    
apc.include_once_override   Off 
apc.lazy_classes    Off 
apc.lazy_functions  Off 
apc.max_file_size   10M 
apc.mmap_file_mask  /tmp/apc.bPS7rB 
apc.num_files_hint  1000    
apc.preload_path    no value    
apc.report_autofilter   Off 
apc.rfc1867 Off 
apc.rfc1867_freq    0   
apc.rfc1867_name    APC_UPLOAD_PROGRESS
apc.rfc1867_prefix  upload_ 
apc.rfc1867_ttl 3600    
apc.serializer  default 
apc.shm_segments    1   
apc.shm_size    256M    
apc.slam_defense    On  
apc.stat    Off 
apc.stat_ctime  Off 
apc.ttl 7200    
apc.use_request_time    On  
apc.user_entries_hint   4096    
apc.user_ttl    0   
apc.write_lock  On  

apc.php reveals the following graph, no matter how long the server runs (cache size fluctuates and hovers at just under 32MB.

See image https://i.stack.imgur.com/2bwMa.png

You can see that the cache is trying to allocate 256MB, but the brown piece of the pie keeps getting recycled at 32MB. This is confirmed as refreshing the apc.php page shows cached file counts that move up and down (implying that the cache is not holding onto all of its files).

Does anyone have an idea of how to get APC to use more than 32 MB for its cache size??

**Note that the identical behavior occurs for eaccelerator, xcache, and APC. I read here:

http://www.litespeedtech.com/support/forum/archive/index.php/t-5072.html

that suEXEC could cause this problem.

3
  • Maybe it's a bug. Simplify your APC php.ini settings and see if it makes any difference. i.e. You probably need to only specify apc.shm_size=256M
    – HTTP500
    Oct 12, 2011 at 17:50
  • It makes a difference in the available memory, but never gets past 32 MB. This has been the case for eaccelerator, xcache, and APC. Could suEXEC be the culprit here?
    – hardy101
    Oct 15, 2011 at 3:46
  • I have same configs and same problem.. Is there a solution? Jun 29, 2013 at 7:12

4 Answers 4

0

This might be a non-starter, but have you tested this with anything other than that wordpress instance? Any chance you really only have ~32MB of cahceable content?

3
  • Hi - thanks. Thought about that, but that explain why my cached file count hits a certain point just below 32 MB, then drops files and and rebuilds to 32 MB, then repeats. I really want to figure this out, and I thank you all for your ideas!
    – hardy101
    Oct 12, 2011 at 22:20
  • MrTuttle - this is a late answer-acceptance, but yes, you're right. Most folks recommend ~32MB per WP instance. I'm running a huge multisite install (200,000 sites) but only one instance of WP itself. So the 32 MB makes total sense. Just wanted to give credit, even though it's belated.
    – hardy101
    Dec 8, 2012 at 15:04
  • @hardy101 appreciated! Plus, it looks like you spent a lot of time doing your homework, so maybe your note will save one of our brethren time in the future. Cheers!
    – MrTuttle
    Dec 14, 2012 at 2:46
1

Your actual issue is the frequent restart of Apache that is preventing APC to build cache. I do not comment on the memory size for wordpress. Are you using cPanel? It has a log rotation feature that before log rotation restart Apache, although it is a graceful restart but clears all APC cache. You can either increase log rotation threshold or see why it reaches to the limit so quickly. Maybe you can enable Piped Log under Apache configuration (in cPanel).

This link will tell you how you can do both.

http://forums.cpanel.net/f5/cpanel-11-25-log-processing-145417.html

0

try upping

apc.shm_segments    1   

then see what happens

1
  • Thanks for the quick response. mmap mode only allows 1 segment. Apache logs state: "PHP Warning: PHP Startup: apc.shm_segments setting ignored in MMAP mode" when setting the flag you suggested. I had tried disabling mmap mode at one point, and the two segments were displayed in apc.php, but still never got past 32 MB.
    – hardy101
    Oct 12, 2011 at 5:01
0

APC will only the cache the code which is actively being used - when it's got plenty of memory, then the only thing which will remove code from the cache is the TTL.

Increasing the TTL will increase occupancy.

3
  • Thank you. I added apc.ttl=7200 but the "Cached Files" number keeps moving up and down on apc.php, indicating to me that it's running out of room and clearing the cache, even though it's only up to 31.9 MB. When it hits that cache size, it purges itself. Still seeking answers. Thanks for the help so far.
    – hardy101
    Oct 12, 2011 at 11:44
  • There's no evidence it's running out of space (and a lot of evidence to the contrary). Increasing the TTL will not prevent code from being expired - just delay it. The occupancy should increase though. Are you suggesting it didn't?
    – symcbean
    Oct 13, 2011 at 10:45
  • Yes, occupancy is not increasing past a certain point, then gets reset every 10 seconds or so. This post litespeedtech.com/support/forum/archive/index.php/t-5072.html suggests that the culprit may be suEXEC, which I am indeed using. Is this a bad thing?
    – hardy101
    Oct 15, 2011 at 3:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .