每天写入5.5GB到1.2GB根卷-以前的水平的4倍

9

问题： 我最近对我的一台服务器进行了改造，在使用之前对其进行了测试，并且运行良好，但是几天前，我注意到对根卷的写入量约为通常的4倍。这不是性能问题-服务器运行正常。

我的改版相当广泛（全面重建），因此就事业而言，我没有太多事情要做。简要地说，我的更改包括：

  • 升级Amazon的Linux（从2011.02到2011.09）-这也导致根卷从ext3更改为ext4
  • 从php-fcgi移到php-fpm（当前使用tcp）
  • 从反向代理（nginx-> Apache）设置转移到仅Nginx
  • 用纯FTPD替换vsftpd
  • 用opendkim代替dkim-proxy
  • 用ispconfig替换webmin
  • 添加清漆作为动态文件的缓存层（这些网站获得的点击量过高，但这是一个实验）
  • 添加交换分区

基本设置：

  • 我的交换空间安装自己的EBS卷上-在写入到交换卷忽略不计-我已经基本上打折以此为原因（有充足的可用内存-无一不free和iostat显示最小的交换使用）。
  • 我的数据（mysql数据库，用户文件（网站），所有日志（来自/ var / log），邮件和清漆文件）都位于其自己的EBS卷上（使用mount --bind）。/mnt/data
  • 我剩下的文件-操作系统和核心服务器应用程序（例如nginx，postfix，dovecot等）-是根卷上唯一的文件-总计1.2GB。

新设置比旧系统运行“更流畅”（速度更快，内存更少等），并且已经稳定了20天（10月中旬），据我所知，这段时间内一直存在较高的写入量。

与我的预期相反，我的读取量很低（就根卷的块和字节而言，我的读取量约为写入量的1.5％）。在过去几天中，我没有更改根卷上的任何内容（例如，新安装的软件等），但是写入量仍然远远高于预期。

目标：确定增加对根卷的写入的原因（本质上，确定它是一个进程（以及哪个进程），不同的（ext4）文件系统还是另一个问题（例如内存））。

系统信息：

  • 平台：亚马逊的EC2（t1.micro）
  • 操作系统：Amazon Linux 2011.09（源自CentOS / RHEL）
  • Linux内核：2.6.35.14-97.44.amzn1.i686
  • 架构：32位/ i686
  • 磁盘：3个EBS卷：
    • xvdap1，root，ext4文件系统（通过noatime挂载）
    • xvdf，数据，xfs文件系统（已安装noatime，usrquota，grpquota）
    • xvdg，交换

根和数据卷每天快照一次-但是，这应该是“读”操作，而不是写操作。（此外，在先前的服务器上使用了相同的做法-先前的服务器也是t1.micro。）

导致我查看I / O的数据包含在我上次AWS账单的详细信息中（该账单高于正常I / O，这并不出乎意料，因为我正在设置此服务器，并在一开始就安装了很多东西月份），然后按附加的EBS卷的CloudWatch指标。我通过推算11月份（当我没有更换服务器时）的I / O活动来估算每月价值，并将其与过去几个月不工作时的I / O进行比较，得出“正常4倍”的数字。在我以前的服务器上。（我没有来自先前服务器的确切iostat数据）。相同的写入量一直持续到11月，为170-330MB /小时。

诊断信息（以下输出的正常运行时间为20.6天）：

Cloudwatch指标：

  • 根卷（写）：5.5GB /天
  • 根卷（读取）：60MB /天
  • 数据量（写）：400MB /天
  • 数据量（读取）：85MB /天
  • 交换量（写）：3MB /天
  • 交换量（读取）：2MB /天

输出：（df -h仅针对根卷）

Filesystem            Size  Used Avail Use% Mounted on
/dev/xvda1            4.0G  1.2G  2.8G  31% /

自从启动此系统以来，使用的空间并未显着增加（对我来说，这表明文件正在更新，而不是创建/附加）。

输出：（iostat -x带有Blk_read，Blk_wrtn添加到）：

Linux 2.6.35.14-95.38.amzn1.i686  11/05/2011      _i686_

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s   Blk_read   Blk_wrtn avgrq-sz avgqu-sz   await  svctm  %util
xvdap1            0.00     3.42    0.03    2.85     0.72    50.19  2534636  177222312   17.68     0.18   60.93   0.77   0.22
xvdf              0.00     0.03    0.04    0.35     1.09     8.48  3853710   29942167   24.55     0.01   24.28   2.95   0.12
xvdg              0.00     0.00    0.00    0.00     0.02     0.04    70808     138160   31.09     0.00   48.98   4.45   0.00

输出： iotop -d 600 -a -o -b

Total DISK READ: 6.55 K/s | Total DISK WRITE: 117.07 K/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
  852 be/4 root          0.00 B     26.04 M  0.00 %  0.42 % [flush-202:1]
  539 be/3 root          0.00 B    528.00 K  0.00 %  0.08 % [jbd2/xvda1-8]
24881 be/4 nginx        56.00 K    120.00 K  0.00 %  0.01 % nginx: worker process
19754 be/4 mysql       180.00 K     24.00 K  0.00 %  0.01 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
 3106 be/4 mysql         0.00 B    176.00 K  0.00 %  0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
19751 be/4 mysql         4.00 K      0.00 B  0.00 %  0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
 3194 be/4 mysql         8.00 K     40.00 K  0.00 %  0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
 3156 be/4 mysql         4.00 K     12.00 K  0.00 %  0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
 3099 be/4 mysql         0.00 B      4.00 K  0.00 %  0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
24216 be/4 web14         8.00 K     10.43 M  0.00 %  0.00 % php-fpm: pool web14
24465 be/4 web19         0.00 B      7.08 M  0.00 %  0.00 % php-fpm: pool web19
 3110 be/4 mysql         0.00 B    100.00 K  0.00 %  0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
  579 be/4 varnish       0.00 B     76.00 K  0.00 %  0.00 % varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 3600 -w 1,1000,120 -u varnish -g varnish
  582 be/4 varnish       0.00 B    144.00 K  0.00 %  0.00 % varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 3600 -w 1,1000,120 -u varnish -g varnish
  586 be/4 varnish       0.00 B      4.00 K  0.00 %  0.00 % varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 3600 -w 1,1000,120 -u varnish -g varnish
  587 be/4 varnish       0.00 B     40.00 K  0.00 %  0.00 % varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 3600 -w 1,1000,120 -u varnish -g varnish
 1648 be/4 nobody        0.00 B      8.00 K  0.00 %  0.00 % in.imapproxyd
18072 be/4 varnish     128.00 K    128.00 K  0.00 %  0.00 % varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 3600 -w 1,1000,120 -u varnish -g varnish
 3101 be/4 mysql         0.00 B    176.00 K  0.00 %  0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
19749 be/4 mysql         0.00 B     32.00 K  0.00 %  0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
19750 be/4 mysql         0.00 B      0.00 B  0.00 %  0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
19752 be/4 mysql         0.00 B    108.00 K  0.00 %  0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
19788 be/4 mysql         0.00 B     12.00 K  0.00 %  0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
  853 be/4 root          4.00 K      0.00 B  0.00 %  0.00 % [flush-202:80]
22011 be/4 varnish       0.00 B    188.00 K  0.00 %  0.00 % varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 3600 -w 1,1000,120 -u varnish -g varnish

总结一下（在10分钟内）上面的内容（并推断为每日值）：

  • [flush-202]每天写入26MB = 3.6GB
  • php-fpm写入17.5MB = 2.4GB /天
  • MySQL写入684KB = 96MB /天
  • Varnish写入580KB = 82MB /天
  • [jbd2]写入528KB = 74MB /天
  • Nginx每天写120KB = 17MB
  • IMAP代理写入8KB = 1.1MB /天

有趣的是，似乎介于两者之间[flush-202]并php-fpm有可能考虑每天的写入量。

使用ftop，我无法跟踪flush或php-fpm写入（例如ftop -p php-fpm。

我的问题至少有一部分来自确定哪些进程正在写入根卷。的上面列出的那些，我希望所有被写入的数据量（由于相关目录符号链接有）（例如nginx，mysql，php-fpm，varnish目录都指向一个不同的EBS卷）

我相信这JBD2是ext4的日志记录阻止设备，并且flush-202是脏页面的后台刷新。的dirty_ratio值为20，而的dirty_background_ratio值为10。脏内存（来自/proc/meminfo）通常介于50-150kB之间。页面大小（getconf PAGESIZE）是系统默认值（4096）。

输出： vmstat -s | grep paged

3248858页面已分页104625313页面已分页

输出： sar -B | grep Average

                pgpgin/s pgpgout/s   fault/s  majflt/s  pgfree/s pgscank/s pgscand/s pgsteal/s    %vmeff
Average:         1.38     39.57    113.79      0.03     36.03      0.38      0.02      0.29     73.66

上面的内容似乎表明有很多页面被调出-但是，我希望页面可以在必要时写入交换分区，而不是根卷。在总内存中，系统通常具有35％的使用率，10％的缓冲区和40％的缓存，15％的未使用（即65％的可用空间）。

输出： vmstat -d

disk- ------------reads------------ ------------writes----------- -----IO------
       total merged sectors      ms  total merged sectors      ms    cur    sec
xvda1 105376  14592 2548092  824418 10193989 12264020 179666824 626582671      0   7872
xvdf  126457    579 3882950  871785 1260822  91395 30081792 32634413      0   4101
xvdg    4827   4048   71000   21358   1897  15373  138160  307865      0     29

vmstat始终显示si并且so值为0

输出： swapon -s

Filename                                Type            Size    Used    Priority
/dev/xvdg                               partition       1048572 9252    -1

由于I / O写操作可能与内存有关，因此我禁用了清漆并重新启动了服务器。这将我的内存配置文件更改为使用率10％，缓冲区2％，缓存20％，未使用68％（即90％可用）。但是，经过10分钟的运行，iotop产生了与以前类似的结果：

  • [flush-202]写了19MB
  • php-fpm写了10MB

在重新启动后的一个小时内，已经向根卷中写入了330MB内存，换出了370K页。

输出 inotifywatch -v -e modify -t 600 -r /[^mnt]*

Establishing watches...
Setting up watch(es) on /bin /boot /cgroup /dev /etc/ home /lib /local /lost+found /opt /proc /root /sbin /selinux /src /sys /usr /var
OK, /bin /boot /cgroup /dev /etc/ home /lib /local /lost+found /opt /proc /root /sbin /selinux /src /sys /usr /var is now being watched.
Total of 6753 watches.
Finished establishing watches, now collecting statistics.
Will listen for events for 600 seconds.
total  modify  filename
23     23      /var/log/
20     20      /usr/local/ispconfig/server/temp/
18     18      /dev/
15     15      /var/log/sa/
11     11      /var/spool/postfix/public/
5      5       /var/log/nginx/
2      2       /var/run/pure-ftpd/
1      1       /dev/pts/

再往上看，几乎所有的写操作都可以归因于每5分钟运行一次（未知）进程并检查各种服务的状态（例如chkservd在cPanel上，但是我不使用cPanel，并没有安装此）。它在10分钟内更新了4个日志文件（cron，maillog，ftp，imapproxy），以及一些相关项（后缀套接字，纯FTPD连接）。其他项目主要是修改过的ispconfig会话，系统记帐更新和无效（不存在的server_name）Web访问尝试（记录到/ var / log / nginx）。

结论和问题：

首先让我说我有点困惑-我通常很彻底，但是我觉得我在这方面缺少明显的东西。显然，flush和php-fpm占大头的写入，但是，我不知道为什么会是这样。首先，让我们以php-fpm-它甚至不应该写入根卷。它的目录（文件和日志）都链接到另一个EBS卷。其次，php-fpm应该编写的主要内容是会话和页面缓存-既小又小-肯定不是1MB / min的数量级（如果这样的话，更像是1K / min）。大多数站点都是只读的，只有偶尔的更新。最后一天修改的所有Web文件的总大小为2.6MB。

其次，考虑刷新-从它的大量写信告诉我，脏页经常被刷新到磁盘-但鉴于我通常具有65％的可用内存和用于交换空间的单独EBS卷，我无法解释为什么这样做影响根卷上的写入，尤其是在发生的情况下。我意识到有些进程会将脏页写入其自己的交换空间（而不是使用系统交换空间），但是可以肯定的是，在重启后立即释放了我的绝大部分内存，我应该不会遇到大量的脏页。如果您确实认为这是原因，请让我知道如何确定哪些进程正在写入其自己的交换空间。

整个脏页的想法很可能只是一个红色鲱鱼，与我的问题完全无关（我希望实际上是这样）。如果是这样的话，我唯一的另一个想法是ext3中不存在与ext4日记相关的内容。除此之外，我目前还没有想法。

更新）：

2011年11月6日：

设置dirty_ratio = 10和dirty_background_ratio = 5；更新为sysctl -p（通过/ proc确认）；重新运行10分钟的iotop测试，结果相似（flush写了17MB，php-fpm写了16MB，MySQL写了1MB，JBD2写了0.7MB）。

我已经更改了我设置要使用的所有符号链接mount --bind。重新启用清漆，重启服务器；重新运行10分钟的iotop测试，结果相似（flush写12.5MB，php-fpm写11.5MB，Varnish写0.5MB，JBD2写0.5MB，MySQL写0.3MB）。

在上述运行中，我的内存配置文件使用率为20％，缓冲区为2％，缓存为58％，未使用为20％（即80％可用），以防万一我在这种情况下对可用内存的解释存在缺陷，这是free -m（t1.micro）的输出。已使用的可用共享缓冲区总数（已缓存）Mem：602478124 0 14347-/ + buffers / cache：116486 Swap：1023 0 1023

一些其他信息：输出： dmesg | grep EXT4

[    0.517070] EXT4-fs (xvda1): mounted filesystem with ordered data mode. Opts: (null)
[    0.531043] EXT4-fs (xvda1): mounted filesystem with ordered data mode. Opts: (null)
[    2.469810] EXT4-fs (xvda1): re-mounted. Opts: (null)

我也同时运行ftop和iotop，并且惊讶地发现iotop中显示的条目没有出现在ftop中。ftop列表被过滤到php-fpm，因为我可以相当可靠地触发对该过程的写入。我注意到php-fpm每页视图大约有2MB的写操作-而且我还没有弄清楚它可能写的是什么-关于确定所写内容的任何想法将不胜感激。

在接下来的几天中，我将尝试关闭日记功能，看看是否会有所改善。虽然目前，我发现自己想知道我是否遇到I / O问题或内存问题（或两者都有）-但是如果遇到问题，我很难看清内存问题。

2011年11月13日：

由于文件系统使用扩展盘区，因此无法将其安装为ext3，此外，尝试将其安装为只读，仅导致将其重新安装为可读写。

该文件系统确实启用了日志功能（128MB日志），如以下所示：

输出： tune2fs -l /dev/sda1 | grep features

has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize

如下所示，在不到一个月的时间里，已向该卷写入了约140GB-每天约5GB。

输出： dumpe2fs -h /dev/sda1

Filesystem volume name:   /
Last mounted on:          /
Filesystem UUID:          af5a3469-6c36-4491-87b1-xxxxxxxxxxxx
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              262144
Block count:              1048576
Reserved block count:     10478
Free blocks:              734563
Free inodes:              210677
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      511
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
RAID stride:              32582
Flex block group size:    16
Filesystem created:       Wed Sep 21 21:28:43 2011
Last mount time:          Sun Nov 13 16:10:11 2011
Last write time:          Sun Oct 16 16:12:35 2011
Mount count:              13
Maximum mount count:      28
Last checked:             Mon Oct 10 03:04:13 2011
Check interval:           0 (<none>)
Lifetime writes:          139 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       18610
Default directory hash:   half_md4
Directory Hash Seed:      6c36b2cc-b230-45e2-847e-xxxxxxxxxxx
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke
Journal size:             128M
Journal length:           32768
Journal sequence:         0x0002d91c
Journal start:            1

继续寻找打开的文件，我尝试fuser在根卷上使用：

输出： fuser -vm / 2>&1 | awk '$3 ~ /f|F/'

root       1111 Frce. dhclient
root       1322 frce. mysqld_safe
mysql      1486 Fr.e. mysqld
root       1508 Frce. dovecot
root       1589 Frce. master
postfix    1600 Frce. qmgr
root       1616 Frce. crond
root       1626 Frce. atd
nobody     1648 Frce. in.imapproxyd
postfix    1935 Frce. tlsmgr
root       2808 Frce. varnishncsa
root      25818 frce. sudo
root      26346 Fr.e. varnishd
postfix   26925 Frce. pickup
postfix   28057 Frce. smtpd
postfix   28070 Frce. showq

不幸的是，没有什么意外的。由于是底层硬件的偶然影响，我恢复了昨天的根卷快照（在最后一天没有任何变化），并用新的替换了实例的根卷。不出所料，这对问题没有影响。

我的下一步是删除日记，但是在尝试之前，我偶然发现了解决方案。

问题出在使用文件支持的mmap的APC中。修复此丢失的磁盘I / O约35倍-达到（估计）每天150MB（而不是5GB）。我可能仍会考虑删除日志记录，因为这似乎是造成该值的主要因素，但是，这个数字暂时还是可以接受的。得出APC结论的步骤已发布在下面的答案中。

amazon-ebs  ext4  io  alternative-php-cache 
— Cyber​​x86
source
3
我的直觉是文件系统日志记录。
— David Schwartz
1
您可能想为此悬赏，只是为了让人们阅读。
— Andrew Case
我只浏览了您的问题，但您尝试过监视“ lsof”的输出。您可以编写一个脚本，该脚本将不断监视lsof的输出，并报告未打开的文件及其大小。等等
— 安德烈（Andrey）
@Andrey-感谢您的建议-使用lsof肯定很有趣。由于我的问题是写（而不是读），所以我用lsof看到的限制是它没有列出写入文件的数量-文件大小本身似乎并不相关。我汇总了一条命令，以查看打开的常规文件以在根卷（而不是其他装载）上进行写入，然后运行该文件watch。只有几个文件（17）-大部分是PID文件或锁定文件，还有一些（不存在）临时文件。watch -d -n 0.5 'lsof / | grep REG | awk '"'"'$4 ~ /.*[wu]/ { print $9}'"'"' | sort -u'
— cyberx86
并非完全正确。我只是运行了一个快速测试：启动了“ dd if = / dev / sda of = / root / test_file”，然后在另一个终端上“ watch -n 1'lsof | grep test_file'”，我看到文件的大小值逐渐增大。
— 安德烈

Answers:

5

由于主要的原因似乎是记录日志，因此这将是我的下一步。但是，为了删除日记，我需要将EBS卷附加到另一个实例。我决定使用一个（一天前的）快照来测试该过程，但是，在删除日记记录之前，我重新运行了10分钟的iotop测试（在测试实例上）。令我惊讶的是，我看到了正常（即未升高）的值，这是第一次flush-202甚至没有出现在列表中。这是一个功能齐全的实例（我也还原了我的数据快照）-自从使用后的12个小时左右，根卷没有任何更改。所有测试都表明，两个服务器上都运行相同的进程。这使我相信原因必须归结为“实时”服务器正在处理的某些请求。

查看显示问题的服务器的iotop输出与看似没有问题的服务器的iotop输出之间的差异，唯一的差异是flush-202和php-fpm。这让我想到，尽管很长一段时间，但这可能是与PHP配置有关的问题。

现在，这部分并不理想-但由于实时服务器上运行的所有服务都不会遭受几分钟的停机时间，因此这并不重要。为了缩小问题的范围，实时服务器上的所有主要服务（postfix，dovecot，imapproxy，nginx，php-fpm，varnish，mysqld，varnishncsa）均已停止，并且iotop测试重新运行-没有提升的磁盘I / O 。服务将分三批重新启动，直到结束为止都是php-fpm。每一批重新启动后，iotop测试确认没有问题。一旦启动php-fpm，问题就会返回。（在测试服务器上模拟几个PHP请求本来就很容易的，但是在这一点上，我不确定它实际上是PHP）。

不幸的是，如果没有PHP，服务器将毫无意义，因此这不是一个理想的结论。但是，由于flush-202似乎暗示了一些与内存有关的信息（尽管有足够的可用内存），所以我决定禁用APC。重新运行iotop测试表明磁盘I / O级别正常。对此问题进行仔细研究后发现，已启用了mmap，并将其 apc.mmap_file_mask设置为/tmp/apc.XXXXXX（此安装的默认设置）。该路径将APC设置为使用文件支持的mmap。只需将这一行注释掉（因此使用默认值-支持匿名内存），然后重新运行iotop测试即可解决问题。

我仍然不知道为什么运行的所有诊断程序都没有将写入内容识别为来自php并进入/ tmp目录中的apc文件。甚至提到/ tmp目录的唯一测试是lsof，但是它列出的文件不存在。

— Cyber​​x86
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.