1

When configuring APC as an opcode cache for PHP, there's a configuration setting called apc.mmap_file_mask. From what I've read there are three ways you can configure it but I don't really understand the implications of each.

  1. /tmp/apc.XXXXXX - (default) "file-backed mmap"
  2. /tmp/apc.shm.XXXXXX - use a "POSIX-style shm_open/mmap"
  3. /dev/zero - "use your kernel's /dev/zero interface to anonymous mmap'ed memory"

Source: http://php.net/manual/en/apc.configuration.php#ini.apc.mmap-file-mask

Can anyone comment on these and what they'd recommend? I'm guessing there will be memory usage and performance ramifications and perhaps security ones, but I don't know if that's the case? From the reading I'm done I'm assuming #2 and #3 are faster, but I thought APC is already using shared memory as it is (as set by apc.shm_size), so I don't understand.

sa289
  • 1,318
  • 2
  • 18
  • 44

1 Answers1

5

/tmp/apc.XXXXXX -> This mmap file mask is a normal filesystem based mmap and uses mkstemp to create a unique temporary file which is mmap'd. The 6 'X's are replaced by the unique string to make the filename unique. This is just writing data to a file in filesystem.

/tmp/apc.shm.XXXXXX -> Note that it_must_ be only /apc.shm.XXXXXX on linux systems. The difference from straight file-backed mmap is this mechanism creates a temporary file via mktemp() call and makes a call to shm_open() which creates and opens a new, or opens an existing, POSIX shared memory object. A POSIX shared memory object is in effect a handle which can be used by unrelated processes to mmap the same region of shared memory. I've not tried this before but I think it can have as minimum as 3 'X's (so apc.shml.XXX also should work).

/dev/zero -> mmap'ing /dev/zero is an anonymous memory mapping which means its the memory object having no associated file and all the contents initialized to zero. If you don't specify mmap_file_mask, the APC would use the anonymous map (with flags MAP_SHARED and MAP_ANON). Thus, specifying /dev/zero and not specifying mmap_file_mask are equivalent in the sense that both of them are anonymous map. Historically, MAP_SHARED and MAP_ANON together in linux had no support before kernel version 2.4.

Performance-wise, 3 will do the best since file-backed mmap'ing has considerably more disk I/O. So, 3 must be the fastest as it has no backed file and is part of actual memory itself, then 2 and 1 finally. However, this is only theory and practical benchmarks across various configuration can prove the reality. However, the disadvantage of anonymous mapping (& shared memory mapping) is that mmap'd memory is not persistent between the application executions thus loosing cache on restart.

Samar
  • 1,106
  • 8
  • 6
  • So if I understand correctly, would #2 be almost as fast as #3 with the difference being the mktemp() call which it sounds like would add a minimal amount of time? Also, would there be any security implications to #3 on shared hosting (the word "anonymous" raised a flag for me but I may be way off base)? Regarding the disadvantage you listed about losing cache on restart, is that just referring to restarting Apache (i.e. cache would persist between different page executions as long as Apache wasn't restarted)? – sa289 Jun 11 '15 at 22:19
  • #2 would not be as fast as #3, IMO but not that slow. For #2, the file may not even exist in the filesystem and data would not be written as aggressively as in file-backed mmap. There's no security implications to #3. Anonymous just means not backed by file in filesystem. I will have to look more carefully on source code but APC does not cache result of data. Instead, it caches opcodes (PHP interpreter does not have to take file into memory, run lexer on it & parse lexing result into opcodes on every req). And, I believe it would be between apache restarts that would result in loss of cache. – Samar Jun 13 '15 at 03:27
  • Is the only drawback to using /dev/zero that cached opcodes wouldn't persist between Apache restarts, and if that weren't an issue, then /dev/zero would be the best way to go? Thanks – sa289 Jun 16 '15 at 18:36
  • @sa289 yes, exactly unless its not supported. – Samar Jun 17 '15 at 03:01