每天 5.5GB 寫入 1.2GB 根卷 - 之前級別的 4 倍

問題： 我最近對我的一台伺服器進行了改造，在使用前對其進行了測試，並且執行良好，但是，幾天前，我注意到對根卷的寫入量大約是通常的 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）。底層 EBS 卷安裝在/mnt/data
• 我剩下的文件——作業系統和核心伺服器應用程序（例如 nginx、postfix、dovecot 等）——是根卷上唯一的東西——總共 1.2GB。

新設置比舊系統執行“更流暢”（更快、更少記憶體等），並且已經穩定了 20 天（10 月中旬）——據我所知，提升的寫入一直存在.

與我的預期相反，我的讀取量很低（我的讀取量約占我寫入量的 1.5%，無論是根卷上的塊數還是字節數）。在過去的幾天裡，我沒有更改根卷上的任何內容（例如新安裝等），但寫入量仍然遠高於預期。

**目標：**確定對根卷的寫入增加的原因（本質上，確定它是一個程序（以及什麼程序）、不同的（ext4）文件系統，還是另一個問題（例如記憶體））。

系統資訊：

• 平台：亞馬遜的EC2（t1.micro）

• O/S：亞馬遜的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都指向不同的 EBS 卷php-fpm）varnish

我相信JBD2是 ext4 的日誌塊設備，並且flush-202是臟頁的後台刷新。dirty_ratio是 20，是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 寫入可能與記憶體相關的預感，我禁用了清漆，並重新啟動了伺服器。這將我的記憶體配置文件更改為 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/min 的數量級（如果那樣的話，更像是 1K/min）。大多數網站都是只讀的，只有偶爾更新。最後一天修改的所有網頁文件的總大小為 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）的輸出。總使用的空閒共享緩衝區記憶體記憶體：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 結論而採取的步驟發佈在下面的答案中。

由於主要原因似乎是寫日記，那將是我的下一步。但是，為了刪除日誌，我需要將 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，但是，它列出的文件不存在。

引用自：https://serverfault.com/questions/328212