APC 3.1.14 Question

[Volion]

Updated APC to 3.1.14, PHP Version 5.4.11, In the setting below, does anyone see anything that needs to be modified?

root@host [~]# php -i | grep -i APC
apc
APC Support => disabled
APC Debugging => Disabled
apc.cache_by_default => On => On
apc.canonicalize => On => On
apc.coredump_unmap => Off => Off
apc.enable_cli => Off => Off
apc.enabled => On => On
apc.file_md5 => Off => Off
apc.file_update_protection => 2 => 2
apc.filters => no value => no value
apc.gc_ttl => 3600 => 3600
apc.include_once_override => Off => Off
apc.lazy_classes => Off => Off
apc.lazy_functions => Off => Off
apc.max_file_size => 2M => 2M
apc.mmap_file_mask => no value => no value
apc.num_files_hint => 1000 => 1000
apc.preload_path => no value => no value
apc.report_autofilter => Off => Off
apc.rfc1867 => Off => Off
apc.rfc1867_freq => 0 => 0
apc.rfc1867_name => APC_UPLOAD_PROGRESS => APC_UPLOAD_PROGRESS
apc.rfc1867_prefix => upload_ => upload_
apc.rfc1867_ttl => 3600 => 3600
apc.serializer => default => default
apc.shm_segments => 1 => 1
apc.shm_size => 256M => 256M
apc.shm_strings_buffer => 4M => 4M
apc.slam_defense => On => On
apc.stat => On => On
apc.stat_ctime => Off => Off
apc.ttl => 0 => 0
apc.use_request_time => On => On
apc.user_entries_hint => 4096 => 4096
apc.user_ttl => 1800 => 1800
apc.write_lock => On => On
igbinary APC serializer ABI => 0
------

 

[melbo]

Here's mine and you can view my working stats (11 hours uptime) here: http://www.survivalmonkey.com/apc.php

apc
APC Support => disabled
APC Debugging => Disabled
MMAP File Mask => /tmp/apc.XXXXXX
apc.cache_by_default => On => On
apc.canonicalize => Off => Off
apc.coredump_unmap => Off => Off
apc.enable_cli => Off => Off
apc.enabled => On => On
apc.file_md5 => Off => Off
apc.file_update_protection => 2 => 2
apc.filters => no value => no value
apc.gc_ttl => 3600 => 3600
apc.include_once_override => Off => Off
apc.lazy_classes => Off => Off
apc.lazy_functions => Off => Off
apc.max_file_size => 5M => 5M
apc.mmap_file_mask => /tmp/apc.XXXXXX => /tmp/apc.XXXXXX
apc.num_files_hint => 2400 => 2400
apc.preload_path => no value => no value
apc.report_autofilter => Off => Off
apc.rfc1867 => Off => Off
apc.rfc1867_freq => 0 => 0
apc.rfc1867_name => APC_UPLOAD_PROGRESS => APC_UPLOAD_PROGRESS
apc.rfc1867_prefix => upload_ => upload_
apc.rfc1867_ttl => 3600 => 3600
apc.serializer => default => default
apc.shm_segments => 1 => 1
apc.shm_size => 256M => 256M
apc.shm_strings_buffer => 4M => 4M
apc.slam_defense => On => On
apc.stat => On => On
apc.stat_ctime => Off => Off
apc.ttl => 3600 => 3600
apc.use_request_time => On => On
apc.user_entries_hint => 0 => 0
apc.user_ttl => 1800 => 1800
apc.write_lock => On => On
igbinary APC serializer ABI => 0

 

[melbo]

I used to have more fragmentation until I added memcache back into the equation. Frag dropped significantly although it will still grow to around 2-3% and then drop back down as it TTLs out. It's pretty low at the moment as we rebooted the server last night.

I noticed that you're already at 4%+ after 16 minutes.

caching section from my config.php:

## Caching
#  http://xenforo.com/community/threads/speed-up-your-board-caching.5699/
#  http://xenforo.com/community/threads/tip-use-apc.6456/
$config['cache']['enabled'] = true;
$config['cache']['frontend'] = 'Core';
$config['cache']['frontendOptions'] = array(
                                        'caching'                      => true,
                                        'automatic_serialization'      => true,
                                        'lifetime'                      => 3600,
 
                                        'cache_id_prefix' => 'SM_'
);
 
 
# Begin Memcached
# http://xenforo.com/community/threads/apc-and-caching.30041/page-3
# http://xenforo.com/community/threads/problem-enabling-memcached.33322/
 
$config['cache']['backend'] = 'Memcached';
$config['cache']['backendOptions'] = array(
'compression' => false,
'servers' => array(
array(
// your memcached server IP /address
'host' => 'localhost',
 
// memcached port
'port' => 11211,
)
)
);
# End Memcached
 
$config['cache']['cacheSessions'] = true;

 

[Andy.N]

I don't have memcached installed so I guess I have to deal with restarting APC daily as fact of life.

 

[melbo]

I think the last line in my config.php is what's causing your troubles. Try commenting out (if you have it)

$config['cache']['cacheSessions'] = true;

restart Apache and see if it helps at all and also if it negatively impacts your site's performance.

 

[melbo]

Whatever you did, it looks like you're hitting around 1.4X% and then dropping back down to 0.8X%. If it stays there, you should be better off until you can install memcache/memcached for backend and user session caching.

 

[Andy.N]

Whatever you did, it looks like you're hitting around 1.4X% and then dropping back down to 0.8X%. If it stays there, you should be better off until you can install memcache/memcached for backend and user session caching.

I just remove the session caching from APC and restart the server.

 

[MattW]

I used to have more fragmentation until I added memcache back into the equation. Frag dropped significantly although it will still grow to around 2-3% and then drop back down as it TTLs out. It's pretty low at the moment as we rebooted the server last night.

Same here, I used to get fragmentation until I moved the backend cache to Libmemcached.

Is there any reason why in the above configs you are all using /tmp/ for the mmap_file_mask? I noticed an improvement and reduction in disk I/O by moving it to shared memory:

apc.mmap_file_mask = "/apc.shm.XXXXXX"

as it's not using the disk to access the cached files.

If compiled with MMAP support by using --enable-mmap this is the mktemp-style file_mask to pass to the mmap module for determining whether your mmap'ed memory region is going to be file-backed or shared memory backed. For straight file-backed mmap, set it to something like /tmp/apc.XXXXXX (exactly 6 Xs). To use POSIX-style shm_open/mmap put a .shm somewhere in your mask. e.g. /apc.shm.XXXXXX. You can also set it to /dev/zero to use your kernel's /dev/zero interface to anonymous mmap'ed memory. Leaving it undefined will force an anonymous mmap.

 

[CTXMedia]

Is there any reason why in the above configs you are all using /tmp/ for the mmap_file_mask? I noticed an improvement and reduction in disk I/O by moving it to shared memory:

apc.mmap_file_mask = "/apc.shm.XXXXXX"

as it's not using the disk to access the cached files.

/tmp on my server is a RAM disk so the net effect is the same - no drive I/O (my server has and SSD not HDD so saving writes is quite useful).

 

[MattW]

/tmp on my server is a RAM disk so the net effect is the same - no drive I/O (my server has and SSD not HDD so saving writes is quite useful).

Nice, I did the same with MySQL and make it use a RAM disk for it's temp tables.

How are you finding the new server? Have you fully migrated over to it?

 

[CTXMedia]

How are you finding the new server? Have you fully migrated over to it?

Fantastic - goes like the clappers and due to the oodles of RAM and SSD the load is nice and low.

 

[melbo]

Same here, I used to get fragmentation until I moved the backend cache to Libmemcached.

Is there any reason why in the above configs you are all using /tmp/ for the mmap_file_mask? I noticed an improvement and reduction in disk I/O by moving it to shared memory:

apc.mmap_file_mask = "/apc.shm.XXXXXX"

as it's not using the disk to access the cached files.

Thank you - made the change and will monitor.

 

[melbo]

I just remove the session caching from APC and restart the server.

Something is quite wrong with your APC after only 22 hours and 16 million cache hits. What else are you running on your server? My (less than 1%) fragmentation comes from a few other applications - XF with memcached creates almost zero (or zero) fragmentation.

 

[Andy.N]

Something is quite wrong with your APC after only 22 hours and 16 million cache hits. What else are you running on your server? My (less than 1%) fragmentation comes from a few other applications - XF with memcached creates almost zero (or zero) fragmentation.
View attachment 39856

Tell me about it.
I have only 2 websites on this server, running latest nginx. mySQL is on another server.
Deebs helped set this up for me and I don't know if the config he used makes any differences when applied on my server.

I don't have memcached installed.

 

[MattW]

Tell me about it.
I have only 2 websites on this server, running latest nginx. mySQL is on another server.
Deebs helped set this up for me and I don't know if the config he used makes any differences when applied on my server.

I don't have memcached installed.

If you are using APC to store the sessions for the forum, then that is where the fragmentation is coming from.

 

[Andy.N]

If you are using APC to store the sessions for the forum, then that is where the fragmentation is coming from.

I already removed the session caching but it still fills up to 100% shortly after 24 hours.
What are other solutions? I don't want to restart my APC few times a week.

 

[MattW]

I already removed the session caching but it still fills up to 100% shortly after 24 hours.
What are other solutions? I don't want to restart my APC few times a week.

You've still got quite a bit of space left in your APC memory, so you could increase the ttl on the files.

I have mine set to 24 hours:

apc.ttl = 86400
apc.user_ttl = 86400

Yours is currently set to 60 minutes

 

[Andy.N]

You've still got quite a bit of space left in your APC memory, so you could increase the ttl on the files.

I have mine set to 24 hours:

apc.ttl = 86400
apc.user_ttl = 86400

Yours is currently set to 60 minutes

Also, increased it as you said. Not sure if it will make any difference or it will fill up within 24 hours again