0

If APC is configured to use mmap does that mean virtual memory will be mapped to disk and I will not be using physical memory ?

As my needs are very basic, rather than using memcached to implement memory based session management I wrote a custom session handler for APC but it appears to me a mmap based installation of APC is still going to be writing and reading from disk and my custom session management will be really be no better, or faster, the the default file session management. Am I misinterpreting mmap?

Wesley
  • 32,320
  • 9
  • 80
  • 116

1 Answers1

0

Basically, mmap is very smart about memory usage. You map a file to memory using mmap, and only the bits of the file that you actually read get into memory. And even better, if multiple processes mmap the same file, it's the same area of memory. When you write to that RAM, mmap won't immediately write to disk, it may hold onto that version of things for a while.

  • mmap for a single process can reduce disk I/O. If you change the same block twice, it's possible it only gets written to disk once.
  • mmap can save physical memory, because only blocks you access get read into memory. (which could be an disk I/O savings, too)
  • mmap is totally awesome if you have multiple processes using the same file via mmap. They share a single copy in memory of that file. This can be used for interprocess communication, and is how shared libraries on Linux only use a single copy of the library in memory.

The only way to be certain is to test (benchmark), but I would expect mmap to work for session handling, as long as you handle locking properly.

freiheit
  • 14,334
  • 1
  • 46
  • 69
  • freiheit, much obliged, thanks for the very concise explanation.So my take is, for session reading I'll typically be pulling from memory but if I'm constantly updating my sessions –  Sep 05 '10 at 22:21
  • ... the difference will not be as significant depending on how the write buffering is set up. As you suggest, my best best is to do some testing. Thanks again. –  Sep 05 '10 at 22:24