5.5GB ditulis setiap hari hingga 1.2GB volume root - 4 kali level sebelumnya

Masalah: Saya baru-baru ini mengubah salah satu server saya, itu diuji sebelum digunakan, dan berfungsi dengan baik, namun, beberapa hari yang lalu, saya perhatikan kira-kira 4 kali jumlah penulisan pada volume root. Ini bukan masalah kinerja - server berfungsi dengan baik.

Pembenahan saya cukup luas (pembangunan kembali penuh) jadi saya tidak punya banyak untuk melanjutkan dalam hal penyebab. Secara singkat, perubahan saya termasuk:

• Memutakhirkan Linux Amazon (dari 2011.02 hingga 2011.09) - yang juga menghasilkan perubahan dari ext3 ke ext4 untuk volume root
• Pindah dari php-fcgi ke php-fpm (saat ini menggunakan tcp)
• Pindah dari pengaturan reverse-proxy (nginx -> apache), ke nginx saja
• Mengganti vsftpd dengan pure-ftpd
• Mengganti dkim-proxy dengan opendkim
• Mengganti webmin dengan ispconfig
• Menambahkan pernis sebagai lapisan caching untuk file dinamis (terlalu banyak untuk volume hit situs ini dapatkan, tetapi ini merupakan percobaan)
• Menambahkan partisi swap

Pengaturan dasar:

• Ruang swap saya dipasang pada volume EBS sendiri - penulisan ke volume swap diabaikan - Saya pada dasarnya mengabaikan ini sebagai penyebabnya (ada banyak memori bebas - dan keduanya freeserta iostatmenunjukkan penggunaan swap yang minimal).
• Data saya (database mysql, file pengguna (situs web), semua log (dari / var / log), mail, dan file pernis pada volume EBS mereka sendiri (menggunakan mount --bind). Volume EBS yang mendasarinya dipasang pada/mnt/data
• File saya yang tersisa - sistem operasi dan aplikasi server inti (mis. Nginx, postfix, dovecot, dll.) - adalah satu-satunya hal pada volume root - total 1,2GB.

Pengaturan baru berjalan 'lebih halus' (lebih cepat, lebih sedikit memori, dll.) Daripada sistem lama, dan telah stabil selama 20 hari (pertengahan Oktober) - sejauh yang saya tahu, tulisan yang ditinggikan telah ada selama ini .

Berlawanan dengan apa yang saya harapkan, saya memiliki volume baca yang rendah (bacaan saya sekitar 1,5% dari tulisan saya, baik dalam hal blok dan byte pada volume root saya). Saya belum mengubah apa pun pada volume root (misalnya instalasi baru, dll) dalam beberapa hari terakhir, namun volume tulis terus jauh lebih tinggi dari yang diharapkan.

Tujuan: untuk menentukan penyebab peningkatan penulisan ke volume root (pada dasarnya, mencari tahu apakah itu merupakan proses (dan proses apa), sistem file (ext4) yang berbeda, atau masalah lain (misalnya memori)).

Sistem Informasi:

• Platform: EC2 Amazon (t1.micro)
• O / S: Linux Amazon 2011.09 (berasal dari CentOS / RHEL)
• Kernel Linux: 2.6.35.14-97.44.amzn1.i686
• Arsitektur: 32-bit / i686
• Disk: 3 volume EBS:
  • xvdap1, root, sistem file ext4 (dipasang dengan noatime)
  • xvdf, data, xfs filesystem (dipasang dengan noatime, usrquota, grpquota)
  • xvdg, tukar

Volume root dan data snapshotted sekali sehari - namun, ini seharusnya operasi 'baca', bukan operasi tulis. (Selain itu, praktik yang sama digunakan pada server sebelumnya - dan server sebelumnya juga merupakan t1.micro.)

Data yang menyebabkan saya untuk melihat I / O adalah dalam rincian AWS bill terakhir saya (yang di atas I / O normal - tidak terduga, karena saya sedang menyiapkan server ini, dan menginstal banyak hal di awal bulan ini), dan selanjutnya pada metrik CloudWatch untuk volume EBS terlampir. Saya tiba di angka '4 kali normal' dengan mengekstrapolasi aktivitas i / o mulai November (ketika saya belum mengubah server) untuk memperkirakan nilai bulanan dan membandingkannya dengan I / O dari beberapa bulan terakhir ketika saya tidak bekerja. di server saya sebelumnya. (Saya tidak punya data iostat yang tepat dari server saya sebelumnya). Kuantitas penulisan yang sama telah bertahan hingga November, 170-330MB / jam.

Informasi diagnostik (waktu aktif untuk keluaran berikut adalah 20,6 hari):

Metrik cloudwatch:

• volume root (tulis): 5.5GB / hari
• volume root (baca): 60MB / hari
• volume data (tulis): 400MB / hari
• volume data (baca): 85MB / hari
• volume swap (tulis): 3MB / hari
• volume swap (baca): 2MB / hari

Output dari: df -h(hanya untuk volume root)

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

Ruang yang digunakan tidak meningkat secara nyata sejak sistem ini diluncurkan (yang bagi saya menyarankan bahwa file sedang diperbarui, tidak dibuat / ditambahkan).

Output dari: iostat -x(dengan Blk_read, Blk_wrtnditambahkan):

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

Output dari: 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

Untuk meringkas di atas (dan memperkirakan nilai harian), sepertinya, selama periode 10 menit:

• [flush-202] menulis 26MB = 3.6GB / hari
• php-fpm menulis 17.5MB = 2.4GB / hari
• MySQL menulis 684KB = 96MB / hari
• Varnish menulis 580KB = 82MB / hari
• [jbd2] menulis 528KB = 74MB / hari
• Nginx menulis 120KB = 17MB / hari
• IMAP Proxy menulis 8KB = 1.1MB / hari

Cukup menarik, akan terlihat bahwa antara [flush-202]dan php-fpmdimungkinkan untuk memperhitungkan volume harian menulis.

Dengan menggunakan ftop, saya tidak dapat melacak flushatau php-fpmmenulis (misalnya ftop -p php-fpm.

Setidaknya sebagian dari masalah saya berasal dari mengidentifikasi proses mana yang ditulis ke volume root. Dari mereka yang tercantum di atas, saya harapkan semua akan menulis untuk volume data (karena direktori yang relevan symlinked ada) (misalnya nginx, mysql, php-fpm, varnishdirektori semua titik untuk volume EBS yang berbeda)

Saya percaya JBD2adalah perangkat blok penjurnalan untuk ext4, dan flush-202merupakan latar belakang halaman yang kotor. Ini dirty_ratioadalah 20 dan dirty_background_ratio10. Memori kotor (dari /proc/meminfo) biasanya antara 50-150kB). Ukuran halaman ( getconf PAGESIZE) adalah default sistem (4096).

Output dari: vmstat -s | grep paged

3248858 halaman halaman 104625313 halaman keluar

Output dari: 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

Di atas nampaknya menyarankan jumlah halaman yang tinggi - tetapi, saya berharap bahwa halaman akan ditulis ke partisi swap saya jika perlu, bukan ke volume root saya. Dari total memori, sistem biasanya memiliki 35% dalam penggunaan, 10% dalam buffer, dan 40% di-cache, 15% tidak digunakan (yaitu 65% gratis).

Output dari: 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

vmstatsecara konsisten menampilkan sidan sonilai 0

Output dari: swapon -s

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

Pada firasat bahwa I / O menulis mungkin terkait memori, saya menonaktifkan pernis, dan me-restart server. Ini mengubah profil memori saya menjadi 10% digunakan, 2% di buffer, dan 20% di-cache, 68% tidak digunakan (yaitu 90% gratis). Namun, selama 10 menit berjalan, iotop memberikan hasil yang sama seperti sebelumnya:

• [flush-202] menulis 19MB
• php-fpm menulis 10MB

Dalam satu jam sejak restart, sudah ada 330MB ditulis ke volume root dengan 370K halaman diganti.

Output dari 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/

Melihat sedikit lebih jauh ke atas, hampir semua penulisan dapat dikaitkan dengan proses (tidak diketahui) yang berjalan setiap 5 menit dan memeriksa status berbagai layanan (seperti chkservdpada cPanel, tapi saya tidak menggunakan cPanel, dan tidak menginstal ini). Itu berjumlah 4 file log (cron, maillog, ftp, imapproxy) diperbarui selama 10 menit - dan beberapa item terkait (soket postfix, koneksi pure-ftpd). Item-item lain yang dimodifikasi terutama adalah sesi config, pembaruan sistem akuntansi, dan upaya akses web yang tidak valid (tidak ada server_name) (masuk ke / var / log / nginx).

Kesimpulan dan Pertanyaan:

Mari saya mulai dengan mengatakan saya agak bingung - saya biasanya cukup teliti, tetapi saya merasa bahwa saya kehilangan sesuatu yang jelas pada yang satu ini. Jelas, flushdan php-fpmmenjelaskan sebagian besar penulisan, saya tidak tahu mengapa ini bisa terjadi. Pertama, mari kita ambil php-fpm - seharusnya tidak menulis ke volume root. Direktori itu (baik file dan log) disinkronkan ke volume EBS lain. Kedua, hal-hal utama yang harus ditulis oleh php-fpm adalah sesi dan cache halaman - yang sedikit dan kecil - tentu saja tidak dalam urutan 1MB / mnt (lebih seperti 1 K / mnt, jika itu). Sebagian besar situs bersifat hanya-baca, dengan hanya pembaruan sesekali. Ukuran total semua file web yang dimodifikasi pada hari terakhir adalah 2.6MB.

Kedua, mempertimbangkan flush - tulisan yang signifikan menunjukkan kepada saya bahwa halaman kotor sering disiram ke disk - tetapi mengingat bahwa saya biasanya memiliki memori bebas 65% dan volume EBS terpisah untuk ruang swap, saya tidak bisa menjelaskan mengapa ini akan mempengaruhi penulisan pada volume root saya, terutama sejauh yang terjadi. Saya menyadari bahwa beberapa proses akan menulis halaman kotor ke ruang swap mereka sendiri (alih-alih menggunakan ruang swap sistem), tetapi tentu saja, segera setelah restart dengan sebagian besar memori saya menjadi bebas, saya tidak boleh berlari ke jumlah substansial dari halaman kotor. Jika Anda yakin ini penyebabnya, beri tahu saya bagaimana saya dapat mengidentifikasi proses mana yang menulis ke ruang swap mereka sendiri.

Sangat mungkin bahwa seluruh ide halaman kotor hanyalah ikan haring merah dan sama sekali tidak terkait dengan masalah saya (saya harap itu sebenarnya). Jika itu masalahnya, satu-satunya ide saya yang lain bahwa ada sesuatu yang berkaitan dengan penjurnalan ext4 yang tidak ada di ext3. Di luar itu, saya saat ini kehabisan ide.

Pembaruan:

6 Nov 2011:

Atur dirty_ratio = 10dan dirty_background_ratio = 5; diperbarui dengan sysctl -p(dikonfirmasi melalui / proc); reran 10 menit tes iotop dengan hasil yang sama (flush menulis 17MB, php-fpm menulis 16MB, MySQL menulis 1MB, dan JBD2 menulis 0,7MB).

Saya telah mengubah semua symlink yang saya siapkan untuk digunakan mount --bind. Pernis diaktifkan kembali, restart server; reran 10 menit tes iotop dengan hasil yang sama (flush menulis 12,5MB, php-fpm menulis 11,5MB, Varnish menulis 0,5MB, JBD2 menulis 0,5MB, dan MySQL menulis 0,3MB).

Seperti pada proses di atas, profil memori saya adalah 20% digunakan, 2% dalam buffer, dan 58% di-cache, 20% tidak digunakan (yaitu 80% gratis). Jika interpretasi saya tentang memori bebas, dalam konteks ini, cacat, di sini adalah output dari free -m(ini adalah t1.micro). total digunakan buffer bersama gratis yang disimpan dalam cache Mem: 602 478 124 0 14 347 - / + buffer / cache: 116 486 Tukar: 1023 0 1023

Beberapa informasi tambahan: Output dari: 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)

Saya juga menjalankan ftop dan iotop secara bersamaan, dan terkejut melihat bahwa entri yang muncul di iotop, tidak muncul di ftop. Daftar ftop difilter ke php-fpm, karena saya bisa memicu penulisan proses itu dengan cukup andal. Saya mencatat sekitar 2MB dari penulisan per tampilan halaman untuk php-fpm - dan saya belum mencari tahu apa yang mungkin bisa ditulis - setiap ide untuk memastikan apa yang sedang ditulis akan dihargai.

Saya akan mencoba mematikan jurnal dalam beberapa hari ke depan, dan melihat apakah itu meningkatkan keadaan. Untuk saat ini, saya mendapati diri saya bertanya-tanya apakah saya memiliki masalah I / O atau masalah memori (atau keduanya) - tetapi saya mengalami kesulitan melihat masalah memori, jika ada.

13 Nov 2011:

Karena sistem file menggunakan extents, tidak mungkin untuk me-mount-nya sebagai ext3, selain itu, upaya untuk me-mount-nya sebagai read-only, hanya membuatnya di-remount menjadi read-write.

Sistem file memang telah mengaktifkan jurnal (jurnal 128MB), seperti terbukti dari yang berikut:

Output dari: 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

Sebagai berikut, sekitar 140GB telah ditulis untuk volume ini dalam waktu kurang dari sebulan - hanya sekitar 5GB / hari.

Output dari: 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

Melanjutkan mencari file yang terbuka, saya mencoba menggunakan fuserpada volume root:

Output dari: 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

Sayangnya, tidak ada yang tidak terduga. Jika itu karena perangkat keras yang mendasarinya, saya mengembalikan snapshot volume root kemarin (tidak ada yang berubah pada hari terakhir), dan mengganti volume root instance dengan yang baru. Seperti yang diharapkan, ini tidak berpengaruh pada masalah.

Langkah saya berikutnya adalah menghapus journalling, namun saya menemukan solusi sebelum sampai ke sana.

Masalahnya terletak pada APC menggunakan mmap yang didukung file. Memperbaiki i / o disk yang dijatuhkan ini sekitar 35x - hingga (diperkirakan) 150MB / hari (bukan 5GB). Saya mungkin masih mempertimbangkan untuk menghapus jurnal karena ini tampaknya menjadi kontributor utama yang tersisa untuk nilai ini, namun, angka ini cukup dapat diterima untuk saat ini. Langkah-langkah yang diambil untuk sampai pada kesimpulan APC diposting dalam jawaban, di bawah ini.

Karena penyebab utama tampaknya adalah penjurnalan, itu akan menjadi langkah saya berikutnya. Untuk menghapus penjurnalan, saya perlu melampirkan volume EBS ke instance lain. Saya memutuskan untuk menguji prosedur menggunakan snapshot (hari tua), namun, sebelum menghapus penjurnalan, saya menjalankan kembali tes iotop 10 menit (pada contoh uji). Yang mengejutkan saya, saya melihat nilai-nilai normal (yaitu non-tinggi), dan ini adalah pertama kalinya yang flush-202bahkan tidak muncul dalam daftar. Ini adalah contoh yang berfungsi penuh (saya mengembalikan snapshot data saya juga) - tidak ada perubahan pada volume root dalam 12 jam atau lebih sejak itu diambil. Semua tes menunjukkan bahwa proses yang sama berjalan di kedua server. Hal ini membuat saya percaya bahwa penyebabnya harus turun ke beberapa permintaan yang diproses oleh server 'live'.

Melihat perbedaan antara keluaran iotop dari server yang menampilkan masalah dan server yang tampaknya identik yang tidak memiliki masalah, satu-satunya perbedaan adalah flush-202dan php-fpm. Ini membuat saya berpikir bahwa, walaupun sulit, mungkin itu adalah masalah yang berkaitan dengan konfigurasi PHP.

Sekarang, bagian ini tidak ideal - tetapi karena tidak ada layanan yang berjalan di server langsung akan menderita beberapa menit downtime, itu tidak masalah. Untuk mempersempit masalah, semua layanan utama (postfix, dovecot, imapproxy, nginx, php-fpm, varnish, mysqld, varnishncsa) pada server langsung dihentikan, dan tes iotop jalankan lagi - tidak ada disk yang ditinggikan i / o . Layanan dimulai kembali dalam 3 batch, meninggalkan php-fpm sampai akhir. Setelah setiap batch restart, tes iotop mengkonfirmasi bahwa tidak ada masalah. Setelah php-fpm dimulai masalah dikembalikan. (Itu akan cukup mudah untuk mensimulasikan beberapa permintaan PHP pada server uji, tetapi pada titik ini, saya tidak yakin itu sebenarnya PHP).

Sayangnya, server akan menjadi agak sia-sia tanpa PHP, jadi ini bukan kesimpulan yang ideal. Namun, karena flush-202sepertinya menyarankan sesuatu yang berkaitan dengan memori (walaupun memiliki banyak memori bebas), saya memutuskan untuk menonaktifkan APC. Menjalankan kembali uji iotop menunjukkan bahwa tingkat disk i / o normal. Melihat lebih dekat ke masalah ini menunjukkan bahwa mmap diaktifkan, dan apc.mmap_file_maskitu diatur ke /tmp/apc.XXXXXX(default untuk instalasi ini). Jalur itu menetapkan APC untuk menggunakan mmap yang didukung file. Cukup mengomentari baris ini (karena itu menggunakan default - anonim memori yang didukung) dan menjalankan kembali tes iotop menunjukkan masalah terselesaikan.

Saya masih tidak tahu mengapa tidak ada diagnosa yang dijalankan tidak mengidentifikasi tulisan yang berasal dari php dan pergi ke file apc di direktori / tmp. Satu-satunya tes yang bahkan menyebutkan direktori / tmp adalah lsof, bagaimanapun, file-file yang terdaftar tidak ada.