Posted by lloydpearsoniv on March 16, 2011 at 5:26pm
4 followers
Jump to:
| Project: | APC - Alternative PHP Cache |
| Version: | 7.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
Issue Summary
I have noticed a huge increase in the amount of fragmentation in APC when using this module. My fragmentation stays well under 1% without this module, when using the this module it increases to double figures.
Comments
#1
If your site does alot of cache_clears you will get more fragmentation. It's not really something this module can help.
#2
Not only that... but if your cache size is too small, you'll end up running out of memory and getting a lot of fragmentation, too. You should only cache small things like cache_bootstrap to start, and keep monitoring (a) fragmentation and (b) the total cache size/usage, and then add another bin, and another, etc.
#3
The facts are;
I give 1024Mb [1Gb] to APC, and for me
about 85Mb is used for the Cached Files [PHP] [daily average]
and about 8Mb is used for the Cached Variables [DATA]
Average Fragmentation: = 0.09%
In my case, with heaps of memory, I cache many Drupal items to APC
$conf += array('cache_inc' => './sites/all/modules/cache_backport/cache.inc',
'cache_backends' => array('./sites/all/modules/apc/drupal_apc_cache.inc',),
'apc_show_debug' => FALSE,
'page_cache_without_database' => TRUE,
'page_cache_invoke_hooks' => FALSE,
'page_cache_maximum_age' => 3600,
'cache_lifetime' => 0,
'session_inc' => './sites/all/modules/cacherouter/session.inc',
'cache_default_class' => 'DrupalAPCCache',
'cache_class_cache' => 'DrupalAPCCache',
'cache_class_cache_block' => 'DrupalAPCCache',
'cache_class_cache_bootstrap' => 'DrupalAPCCache',
'cache_class_cache_content' => 'DrupalAPCCache',
'cache_class_cache_filter' => 'DrupalAPCCache',
'cache_class_cache_form' => 'DrupalAPCCache',
'cache_class_cache_menu' => 'DrupalAPCCache',
'cache_class_cache_page' => 'DrupalAPCCache',
'cache_class_cache_pathdst' => 'DrupalAPCCache',
'cache_class_cache_pathsrc' => 'DrupalAPCCache',
'cache_class_cache_session' => 'DrupalAPCCache',
'cache_class_cache_session_user' => 'DrupalAPCCache',
'cache_class_cache_update' => 'DrupalAPCCache',
'cache_class_cache_users' => 'DrupalAPCCache',
'cache_class_cache_views' => 'DrupalAPCCache',
'cache_class_cache_views_data' => 'DrupalAPCCache',
);
My Linux php.ini (in reference to APC) has the following settings:
[apc]
; Notes: Our 'APC' is STATICALLY compiled into PHP
; ini only settings, all the values here is default unless explained
apc.enabled = 1
apc.shm_segments = 1
# Notes: Our PHP Max Memory Setting = memory_limit = 512M; we double this
# Old opcodes stay in cache until all old requests satisfied. Leave headroom (up to 2x normal size)
apc.shm_size = 1024M
# TTL for PHP = 8 hours
apc.ttl = 28800
# TTL for USER = 4 hours
apc.user_ttl = 14400
apc.gc_ttl = 3600
apc.enable_cli = 0
apc.mmap_file_mask = "/dev/zero"
apc.max_file_size = 4M
# Notes: apc.num_files_hint + apc.user_entries_hint are used by APC to
# help optimize its memory usage when creating the cached memory space
apc.num_files_hint = 2048
apc.user_entries_hint = 8000
# Notes: apc.stat = 0; for production servers: = No disk IO to check if the file has been changed
# With the above we have to restart server to get new (changed) files
# Note: Good to use apc.stat_ctime = 1, if apc.stat = 1
apc.stat = 1
apc.stat_ctime = 1
apc.slam_defense = 0
apc.write_lock = 1
apc.file_update_protection = 2
apc.rfc1867 = 1
# Notes: apc.include_once_override = 1; is NOT recommended for PHP 5.3.x+
apc.include_once_override = 0
apc.lazy_classes = 1
apc.lazy_functions = 1
apc.filters = ""
apc.cache_by_default = 1
apc.report_autofilter = 0
apc.localcache = 1
apc.localcache_size = 512
apc.file_md5 = 1
apc.serializer = igbinary
[igbinary]
igbinary.compact_strings = 0
APC fragmentation occurs because of:
In some cases, it is better to let the PHP APC TTL purge old data
rather than relying on Drupal [cache] methods.
#4