apc.mmap_file_mask 到底起什么作用?

apc.mmap_file_mask 到底起什么作用?

我想在共享环境中使用 APC,但主要问题当然是操作码共享。

为了解决这个问题,我考虑过为每个用户使用不同的 apc.mmap_file_mask(它们通过 php-fpm 进行 chrooted),这样 APC 创建的“文件”就不会被共享,而是属于用户个人。

当然,我注意到我错了,原因有很多……其中最大的一个是关于“apc.mmap_file_mask 到底做了什么?”:我认为它就像一个指向 APC 使用的内存区域的指针,但我对此不太确定。
当然,在我使用的路径 (/tmp/apc.XXXXXX) 中没有文件:机器的 /tmp 上没有文件,chrooted 环境 (/home/vhosts/0001/tmp) 中也没有文件。
那么,apc.mmap_file_mask 到底做了什么?

我的实际配置是:

apc.mmap_file_mask = /tmp/apc.XXXXXX
apc.num_files_hint = 2048
apc.max_file_size = 10M
apc.ttl = 7200

我已经检查了 phpinfo() 发生的情况,它没有转换值:它仍然给我/tmp/apc.XXXXXX(但 apc.php 说缓存被命中并且我有更好的时间值...因此它正在工作)。

答案1

您是否尝试过在活动 Web 服务器上使用 APC.php?如果您使用的是 SHM 而不是 MMAP,这可以解释这一点。文件掩码只是允许它根据您的指定将带有随机数字的 ap 文件保存到特定位置。您甚至可以按照此处的博客文章将其发送到 /dev/zerohttp://www.nigeldunn.com/2011/05/02/unable-to-allocate-memory-pool/

以下是各种内存/文件位置的解释https://stackoverflow.com/questions/904581/shmem-vs-tmpfs-vs-mmap

我不完全确定我的答案,但您可能正在使用 SHM,因此 mmap mask 的参数可能不适用。

加载 APC.php 后也尝试一下

ls /dev/shm

答案2

如果有人有用的话,这些文件几乎立即被删除,这就是为什么你无法通过 ls 看到它们(除非你恰好在正确的时间运行 ls)。如果你想看到 APC 在 apc.mmap_file_mask 指定的目录中创建和删除的文件,你可以使用 inotify-tools 来监视该目录中的文件系统活动。

只需安装它并切换到 apc.mmap_file_mask 目录并运行以下命令。如果其他进程将该目录用于其他用途(例如 /tmp 的情况),您可以将输出通过管道传输到 grep 并查找与您的 mmap_file_mask 设置匹配的文件名部分,例如“apc”。

/usr/bin/inotifywait -mr -e attrib,create,delete,modify,move --format '|%w/%f| %e %T' --timefmt '%Y-%m-%d-%H-%M-%S' .

#example output:

Setting up watches.  Beware: since -r was given, this may take a while!
Watches established.
|.//apc.wi3mjq| CREATE 2014-07-09-20-59-01
|.//apc.wi3mjq| MODIFY 2014-07-09-20-59-01
|.//apc.wi3mjq| DELETE 2014-07-09-20-59-01
|.//apc.EQs3Up| CREATE 2014-07-09-20-59-01
|.//apc.EQs3Up| MODIFY 2014-07-09-20-59-01
|.//apc.EQs3Up| DELETE 2014-07-09-20-59-01
|.//apc.IpNU5o| CREATE 2014-07-09-20-59-01
|.//apc.IpNU5o| MODIFY 2014-07-09-20-59-01
|.//apc.QnNU5o| CREATE 2014-07-09-20-59-01
|.//apc.QnNU5o| MODIFY 2014-07-09-20-59-01
|.//apc.QnNU5o| DELETE 2014-07-09-20-59-01

附注一下,此技巧也适用于查看 MySQL 的 tmpdir 中的临时表活动。

相关内容