问题： 我最近改造了我的一台服务器，在使用前进行了测试，运行良好，但是几天前，我注意到根卷的写入量大约是平时的 4 倍。这不是性能问题 - 服务器运行良好。
我的改造相当广泛（完全重建），因此我没有太多可以追溯的原因。简而言之，我的改变包括：
- 升级 Amazon 的 Linux（从 2011.02 到 2011.09）——这也导致根卷从 ext3 更改为 ext4
- 从 php-fcgi 移至 php-fpm（当前使用 tcp）
- 从反向代理（nginx -> apache）设置转移到仅使用 nginx
- 使用 pure-ftpd 替换 vsftpd
- 用 opendkim 替换 dkim-proxy
- 用 ispconfig 替换 webmin
- 添加 varnish 作为动态文件的缓存层（对于这些网站的点击量来说有点过度，但这只是一次实验）
- 添加交换分区
基本设置：
- 我的交换空间安装在它自己的 EBS 卷上 - 对交换卷的写入可以忽略不计 - 我基本上已经将其排除在原因之外（有足够的可用内存 - 并且都
free显示iostat最少的交换使用情况）。 - 我的数据（mysql 数据库、用户文件（网站）、所有日志（来自 /var/log）、邮件和 varnish 文件位于它们自己的 EBS 卷上（使用
mount --bind）。底层 EBS 卷安装在/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目录都指向不同的 EBS 卷）mysqlphp-fpmvarnish
我相信JBD2是 ext4 的日志块设备，flush-202是脏页的后台刷新。是dirty_ratio20，是dirty_background_ratio10。脏内存（来自/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 写入可能与内存有关，因此我禁用了 varnish，然后重新启动了服务器。这将我的内存配置文件更改为 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）以及一些相关项目（postfix 套接字、纯 ftpd 连接）。其他项目主要是修改的 ispconfig 会话、系统记帐更新和无效（不存在的 server_name）Web 访问尝试（记录到 /var/log/nginx）。
结论和问题：
首先我要说的是，我有点困惑 - 我通常都相当彻底，但我觉得在这一点上我忽略了一些显而易见的东西。显然，flush考虑php-fpm到大部分写入，我不知道为什么会这样。首先，让我们以 php-fpm 为例 - 它甚至不应该写入根卷。它的目录（文件和日志）都符号链接到另一个 EBS 卷。其次，php-fpm 应该写入的主要内容是会话和页面缓存 - 它们既少又小 - 当然不是 1MB/分钟的数量级（更像是 1K/分钟，如果是的话）。大多数网站都是只读的，只偶尔更新。过去一天修改的所有 Web 文件的总大小为 2.6MB。
其次，考虑到刷新 - 它的大量写入表明脏页经常被刷新到磁盘 - 但考虑到我通常有 65% 的可用内存和一个单独的 EBS 卷用于交换空间，我无法解释为什么这会影响我的根卷上的写入，尤其是发生这种情况的程度。我意识到有些进程会将脏页写入它们自己的交换空间（而不是使用系统交换空间），但可以肯定的是，在重新启动后，由于我的绝大多数内存都是空闲的，我不应该遇到任何大量的脏页。如果您确实认为这是原因，请告诉我如何确定哪些进程正在写入它们自己的交换空间。
完全有可能整个脏页的想法只是一种转移注意力的花招，与我的问题完全无关（我希望确实如此）。如果是这样的话，我唯一的其他想法是，ext4 日志记录中存在一些与 ext3 中不存在的东西。除此之外，我目前没有其他想法了。
更新）：
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。重新启用 varnish，重新启动服务器；重新运行 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）的输出。总使用空闲共享缓冲区缓存内存：602 478 124 0 14 347 -/+ 缓冲区/缓存：116 486 交换：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 结论所采取的步骤发布在下面的答案中。
答案1
由于主要原因似乎是日志记录，因此这将是我的下一步。但是，为了删除日志记录，我需要将 EBS 卷附加到另一个实例。我决定使用（一天前的）快照测试该过程，但是，在删除日志记录之前，我重新运行了 10 分钟的 iotop 测试（在测试实例上）。令我惊讶的是，我看到了正常（即未升高）的值，这是第一次flush-202甚至没有出现在列表中。这是一个功能齐全的实例（我也恢复了我的数据的快照） - 自拍摄以来的 12 小时内，根卷没有任何变化。所有测试都表明，两台服务器上都在运行相同的进程。这使我相信原因一定是“实时”服务器正在处理的一些请求。
查看出现问题的服务器的 iotop 输出与看似相同但没有问题的服务器之间的差异，唯一的区别是flush-202和php-fpm。这让我想到，虽然可能性不大，但也许是与 PHP 配置有关的问题。
现在，这部分并不理想 - 但由于实时服务器上运行的任何服务都不会受到几分钟停机的影响，所以这并不重要。为了缩小问题范围，实时服务器上的所有主要服务（postfix、dovecot、imapproxy、nginx、php-fpm、varnish、mysqld、varnishncsa）都已停止，并重新运行 iotop 测试 - 没有提升磁盘 i/o。服务分 3 批重新启动，将 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，但它列出的文件不存在。