0

I'm trying to understand the apc.shm_strings_buffer setting in apc.ini. After restarting PHP, the pie chart in the APC admin shows 8MB of cache is already used, even though there are no cached entries (except for apc.php, of course). I've found this relates to the apc.shm_strings_buffer setting.

Can someone help me understand what the setting means? The config file notes that this is the "shared memory size reserved for strings, with M/G suffixe", but I fail to comprehend.

I'm using APC with PHP-FPM.

Danack
  • 24,939
  • 16
  • 90
  • 122
redburn
  • 542
  • 4
  • 24

1 Answers1

2

The easy part to explain is "with M/G suffixe" which means that if you set it to 8M, then 8 megabytes would be allocated, or 1G would allocated 1 gigabyte of memory.

The more difficult bit to explain is that it's a cache for storing strings that are used internally by APC when it's compiling and caching opcode.

The config value was introduced in this change and the bulk of the change was to add apc_string.c to the APC project. The main function that is defined in that C file is apc_new_interned_string which is then used in apc_string_pmemcpy in apc_compile.c. the rest of the APC module to store strings.

For example in apc_compile.c

/* private members are stored inside property_info as a mangled
 * string of the form:
 *      \0<classname>\0<membername>\0
 */
CHECK((dst->name = apc_string_pmemcpy((char *)src->name, src->name_length+1, pool TSRMLS_CC)));

When APC goes to store a string, the function apc_new_interned_string looks to see if it that string is already saved in memory by doing a hash on the string, and if it is already stored in memory, it returns the previous instance of the stored string.

Only if that string is not already stored in the cache does a new piece of memory get allocated to store the string.

If you're running PHP with PHP-FPM, I'm 90% confident that the cache of stored strings is shared amongst all the workers in a single pool, but am still double-checking that.

The whole size allocated to storing shared strings is allocated when PHP starts up - it's not allocated dynamically. So it's to be expected that APC shows the 8MB used for the string cache, even though hardly any strings have actually been cached yet.

Edit

Although this answers what it does, I have no idea how to see how much of the shared string buffer is being used, so there's no way of knowing what it should be set to.

Danack
  • 24,939
  • 16
  • 90
  • 122
  • Your answer certainly clears things up a bit, although the concept of the internally used string cache still boggles my mind (which is why it took me a while to comment). For a change that was introduced three years ago, there´s remarkably little information available about it, so, like you said, I really have no idea what to set it to (I guess I'll just stick to the 8M default?). – redburn Jun 17 '13 at 15:15
  • Sure why not :) btw I just found out that apc cache is borderline deprecated as it's not under active development, and is being replaced by the ZendOptimizer which has been renamed as OPCache, so as long as everythings working now I'd just leave it. btw OPCache does have decent documentation https://github.com/zendtech/ZendOptimizerPlus/blob/master/README – Danack Jun 17 '13 at 15:26
  • That's good to know, thanks. Not sure how I feel about it, since APC works rather well, and OPCache apparently will have no user cache. Anyway, thanks for your help, I think your answer clears things up as much as possible, so I'm now marking it as such. – redburn Jun 17 '13 at 22:18
  • I'm in the same position - I use APC, it works, and I also use it for caching user data locally. The project https://github.com/krakjoe/apcu for continuing to use APC for user data appears not quite ready for prime time - so I'm just going to stick with APC for at least 6 months. – Danack Jun 17 '13 at 22:29