5.5GB escritos diariamente a 1.2GB de volumen raíz - 4 veces niveles anteriores

Problema: Recientemente renové uno de mis servidores, lo probé antes de usarlo y funciona bien, sin embargo, hace unos días, noté aproximadamente 4 veces la cantidad habitual de escrituras en el volumen raíz. Esto no es un problema de rendimiento: el servidor funciona bien.

Mi renovación fue bastante extensa (una reconstrucción completa), así que no tengo mucho para continuar en términos de causa. Brevemente, mis cambios incluyen:

• Actualización de Linux de Amazon (de 2011.02 a 2011.09), que también resultó en un cambio de ext3 a ext4 para el volumen raíz
• Pasando de php-fcgi a php-fpm (actualmente usando tcp)
• Pasar de una configuración de proxy inverso (nginx -> apache) a solo nginx
• Reemplazar vsftpd con pure-ftpd
• Reemplazar dkim-proxy con opendkim
• Reemplazar webmin con ispconfig
• Agregar barniz como capa de almacenamiento en caché para archivos dinámicos (exagerado por el volumen de visitas que obtienen estos sitios, pero es un experimento)
• Agregar una partición de intercambio

Configuración básica:

• Mi espacio de intercambio está montado en su propio volumen EBS (las escrituras en el volumen de intercambio son insignificantes). Esencialmente, he descartado esto como la causa (hay suficiente memoria libre, y ambas, freey iostatmuestran un uso mínimo de intercambio).
• Mis datos (base de datos mysql, archivos de usuario (sitios web), todos los registros (desde / var / log), correo y archivos de barniz en su propio volumen EBS (usando mount --bind). El volumen EBS subyacente se monta en/mnt/data
• Mis archivos restantes (sistema operativo y aplicaciones de servidor central (por ejemplo, nginx, postfix, dovecot, etc.) son lo único en el volumen raíz: un total de 1.2GB.

La nueva configuración se ejecuta 'más suave' (más rápido, menos memoria, etc.) que el sistema anterior, y se ha mantenido estable durante 20 días (mediados de octubre), por lo que puedo decir, las escrituras elevadas han existido durante todo este tiempo .

Al contrario de lo que esperaría, tengo un volumen de lectura bajo (mis lecturas representan aproximadamente el 1.5% de mis escrituras, tanto en términos de bloques como de bytes en mi volumen raíz). No he cambiado nada en el volumen raíz (por ejemplo, nuevas instalaciones, etc.) en los últimos días, pero el volumen de escritura continúa siendo mucho mayor de lo esperado.

Objetivo: determinar la causa del aumento de escrituras en el volumen raíz (esencialmente, averiguar si es un proceso (y qué proceso), el sistema de archivos diferente (ext4) u otro problema (por ejemplo, memoria)).

Información del sistema:

• Plataforma: EC2 de Amazon (t1.micro)
• O / S: Amazon's Linux 2011.09 (derivado de CentOS / RHEL)
• Kernel de Linux: 2.6.35.14-97.44.amzn1.i686
• Arquitectura: 32 bits / i686
• Discos: 3 volúmenes EBS:
  • xvdap1, root, sistema de archivos ext4 (montado con noatime)
  • xvdf, datos, sistema de archivos xfs (montado con noatime, usrquota, grpquota)
  • xvdg, swap

Los volúmenes raíz y de datos se capturan una vez al día; sin embargo, esta debería ser una operación de 'lectura', no de escritura. (Además, se utilizó la misma práctica en el servidor anterior, y el servidor anterior también era un t1.micro).

Los datos que me llevaron a investigar las E / S estaban en los detalles de mi última factura de AWS (que tenía E / S superiores a lo normal, no inesperado, ya que estaba configurando este servidor e instalando muchas cosas al principio del mes), y posteriormente en las métricas de CloudWatch para los volúmenes EBS adjuntos. Llego a la cifra '4 veces normal' extrapolando la actividad de E / S de noviembre (cuando no he alterado el servidor) para estimar un valor mensual y comparándolo con la E / S de los últimos meses cuando no estaba trabajando en mi servidor anterior (No tengo datos exactos de iostat de mi servidor anterior). La misma cantidad de escrituras ha persistido hasta noviembre, 170-330MB / h.

Información de diagnóstico (el tiempo de actividad de las siguientes salidas es de 20,6 días):

Métricas de Cloudwatch:

• volumen raíz (escritura): 5.5GB / día
• volumen raíz (lectura): 60 MB / día
• volumen de datos (escritura): 400 MB / día
• volumen de datos (lectura): 85 MB / día
• Volumen de intercambio (escritura): 3 MB / día
• volumen de intercambio (lectura): 2 MB / día

Salida de: df -h(solo para volumen raíz)

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

El espacio utilizado no ha aumentado notablemente desde que se lanzó este sistema (lo que para mí sugiere que los archivos se actualizan, no se crean / anexan).

Salida de: iostat -x(con Blk_read, Blk_wrtnagregado en):

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

Salida de: 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

Para resumir lo anterior (y extrapolar a valores diarios) se ve, durante el período de 10 minutos:

• [flush-202] escribió 26MB = 3.6GB / día
• php-fpm escribió 17.5MB = 2.4GB / día
• MySQL escribió 684KB = 96MB / día
• Barniz escribió 580 KB = 82 MB / día
• [jbd2] escribió 528KB = 74MB / día
• Nginx escribió 120 KB = 17 MB / día
• El proxy IMAP escribió 8 KB = 1.1 MB / día

Curiosamente, parece que entre [flush-202]y php-fpmes posible dar cuenta del volumen diario de escrituras.

Utilizando ftop, soy incapaz de localizar ya sea la flusho php-fpmlas escrituras (por ejemplo ftop -p php-fpm.

Al menos parte de mi problema proviene de identificar qué procesos están escribiendo en el volumen raíz. De los mencionados anteriormente, que se puede esperar que todos sean escrito al volumen de datos (ya que los directorios pertinentes se enlace simbólico allí) (por ejemplo nginx, mysql, php-fpm, varnishdirectorios, apuntan a un volumen EBS diferente)

Creo que JBD2es el dispositivo de bloqueo de diario para ext4, y flush-202es el fondo de las páginas sucias. El dirty_ratioes 20 y el dirty_background_ratio10. La memoria sucia (de /proc/meminfo) era típicamente entre 50-150kB). El tamaño de página ( getconf PAGESIZE) es el valor predeterminado del sistema (4096).

Salida de: vmstat -s | grep paged

3248858 páginas paginada en 104625313 páginas paginada

Salida de: 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

Lo anterior parece sugerir una gran cantidad de páginas paginadas; sin embargo, esperaría que las páginas se escribieran en mi partición de intercambio si fuera necesario, no en mi volumen raíz. De la memoria total, el sistema generalmente tiene 35% en uso, 10% en memorias intermedias y 40% en caché, 15% sin usar (es decir, 65% libre).

Salida de: 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

vmstatmuestra consistentemente siy sovalores de 0

Salida de: swapon -s

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

En el presentimiento de que las escrituras de E / S pueden estar relacionadas con la memoria, deshabilité el barniz y reinicié el servidor. Esto cambió mi perfil de memoria a 10% en uso, 2% en memorias intermedias y 20% en caché, 68% sin usar (es decir, 90% libre). Sin embargo, durante una carrera de 10 minutos, iotop dio resultados similares a los anteriores:

• [flush-202] escribió 19MB
• php-fpm escribió 10MB

En la hora desde el reinicio, ya se han escrito 330 MB en el volumen raíz con 370 mil páginas intercambiadas.

Salida de 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/

Mirando un poco más allá de lo anterior, casi todas las escrituras se pueden atribuir a un proceso (desconocido) que se ejecuta cada 5 minutos y que verifica el estado de una variedad de servicios (como chkservden cPanel, pero no uso cPanel, y no instalé esto). Asciende a 4 archivos de registro (cron, maillog, ftp, imapproxy) actualizados durante los 10 minutos, y algunos elementos relacionados (sockets postfix, conexiones de ftpd puro). Los otros elementos son principalmente sesiones ispconfig modificadas, actualizaciones de contabilidad del sistema e intentos de acceso web no válidos (nombre_servidor inexistente) (registrados en / var / log / nginx).

Conclusiones y preguntas:

Permítanme comenzar diciendo que estoy un poco perplejo: generalmente soy bastante minucioso, pero siento que me falta algo obvio en este caso. Claramente, flushy php-fpmrepresentan la mayor parte de las escrituras, sin embargo, no sé por qué este podría ser el caso. En primer lugar, tomemos php-fpm: ni siquiera debería estar escribiendo en el volumen raíz. Sus directorios (tanto archivos como registros) están enlazados a otro volumen EBS. En segundo lugar, lo principal que debería escribir php-fpm son las sesiones y los cachés de página, que son pocos y pequeños, ciertamente no del orden de 1 MB / min (más como 1 K / min, si es así). La mayoría de los sitios son de solo lectura, con actualizaciones ocasionales. El tamaño total de todos los archivos web modificados en el último día es de 2.6 MB.

En segundo lugar, teniendo en cuenta el vaciado, las escrituras significativas me sugieren que las páginas sucias se descargan con frecuencia en el disco, pero dado que generalmente tengo un 65% de memoria libre y un volumen EBS separado para el espacio de intercambio, no puedo explicar por qué esto afectar las escrituras en mi volumen raíz, especialmente en la medida en que está ocurriendo. Me doy cuenta de que algunos procesos escribirán páginas sucias en su propio espacio de intercambio (en lugar de usar el espacio de intercambio del sistema), pero seguramente, inmediatamente después de un reinicio con la gran mayoría de mi memoria libre, no debería encontrarme con una cantidad sustancial de páginas sucias Si cree que esta es la causa, avíseme cómo puedo identificar qué procesos están escribiendo en su propio espacio de intercambio.

Es completamente posible que toda la idea de páginas sucias sea simplemente un arenque rojo y no esté completamente relacionada con mi problema (espero que sea realmente). Si ese es el caso, mi única otra idea es que hay algo relacionado con el diario ext4 que no estaba presente en ext3. Más allá de eso, actualmente estoy sin ideas.

Actualización (es):

6 de noviembre de 2011:

Conjunto dirty_ratio = 10y dirty_background_ratio = 5; actualizado con sysctl -p(confirmado a través de / proc); reran la prueba iotop de 10 minutos con resultados similares (flush escribió 17MB, php-fpm escribió 16MB, MySQL escribió 1MB y JBD2 escribió 0.7MB).

He cambiado todos los enlaces simbólicos que configuré para usar mount --binden su lugar. Barniz reactivado, servidor reiniciado; reran la prueba iotop de 10 minutos con resultados similares (flush escribió 12.5MB, php-fpm escribió 11.5MB, Varnish escribió 0.5MB, JBD2 escribió 0.5MB y MySQL escribió 0.3MB).

Al igual que en la ejecución anterior, mi perfil de memoria estaba 20% en uso, 2% en búferes y 58% en caché, 20% sin usar (es decir, 80% libre) En caso de que mi interpretación de memoria libre, en este contexto, sea defectuosa, Aquí está la salida de free -m(este es un t1.micro). total utilizado buffers compartidos gratuitos en caché Mem: 602 478 124 0 14 347 - / + buffers / caché: 116 486 Swap: 1023 0 1023

Alguna información adicional: Salida de: 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)

También ejecuté ftop e iotop simultáneamente, y me sorprendió notar que las entradas que aparecían en iotop no aparecían en ftop. La lista ftop se filtró a php-fpm, ya que podía activar las escrituras de ese proceso de manera bastante confiable. Noté alrededor de 2 MB de escrituras por página vista para php-fpm, y aún no he descubierto lo que podría estar escribiendo, cualquier idea sobre la determinación de lo que se está escribiendo sería apreciada.

Intentaré apagar el diario en los próximos días y ver si eso mejora las cosas. Sin embargo, por el momento, me pregunto si tengo un problema de E / S o un problema de memoria (o ambos), pero estoy teniendo dificultades para ver el problema de memoria, si es que hay uno.

13 de noviembre de 2011:

Como el sistema de archivos usa extensiones, no fue posible montarlo como ext3, además, los intentos de montarlo como de solo lectura, simplemente resultaron en el montaje como lectura-escritura.

El sistema de archivos tiene el registro en diario habilitado (registro de 128 MB), como se desprende de lo siguiente:

Salida de: 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

Según lo siguiente, se han escrito aproximadamente 140 GB en este volumen en poco menos de un mes, solo unos 5 GB / día.

Salida de: 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

Continuando buscando archivos abiertos, intenté usar fuseren el volumen raíz:

Salida de: 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

Nada inesperado, desafortunadamente. En caso de que fuera debido al hardware subyacente, restauré la instantánea del volumen raíz de ayer (nada había cambiado en el último día) y reemplacé el volumen raíz de la instancia con el nuevo. Como se esperaba, esto no tuvo ningún efecto sobre el problema.

Mi siguiente paso habría sido eliminar el diario, sin embargo, me topé con la solución antes de llegar a eso.

El problema radica en APC usando mmap respaldado por archivos. La fijación de esta caída de E / S de disco en aproximadamente 35x - a (aproximadamente) 150 MB / día (en lugar de 5 GB). Todavía podría considerar eliminar el diario, ya que parece ser el principal contribuyente restante de este valor, sin embargo, este número es bastante aceptable por el momento. Los pasos dados para llegar a la conclusión de APC se publican en una respuesta, a continuación.

Dado que la causa principal parecía estar en el diario, ese habría sido mi siguiente paso. Sin embargo, para eliminar el registro en diario, necesitaría adjuntar el volumen EBS a otra instancia. Decidí probar el procedimiento usando una instantánea (de un día), sin embargo, antes de eliminar el diario, volví a ejecutar la prueba iotop de 10 minutos (en la instancia de prueba). Para mi sorpresa, vi valores normales (es decir, no elevados), y esta fue la primera vez que flush-202ni siquiera apareció en la lista. Esta fue una instancia totalmente funcional (también restauré instantáneas de mis datos): no hubo cambios en el volumen raíz en las 12 horas más o menos desde que se tomó. Todas las pruebas mostraron que se ejecutaban los mismos procesos en ambos servidores. Esto me llevó a creer que la causa debe reducirse a algunas solicitudes que el servidor 'en vivo' está procesando.

Mirando las diferencias entre las salidas iotop del servidor que muestra el problema y el servidor aparentemente idéntico que no tuvo ningún problema, las únicas diferencias fueron flush-202y php-fpm. Esto me hizo pensar que, aunque fuera una posibilidad remota, tal vez era un problema relacionado con la configuración de PHP.

Ahora, esta parte no era ideal, pero dado que ninguno de los servicios que se ejecutan en el servidor en vivo sufriría unos minutos de tiempo de inactividad, realmente no importaba. Para reducir el problema, se detuvieron todos los servicios principales (postfix, dovecot, imapproxy, nginx, php-fpm, varnish, mysqld, varnishncsa) en el servidor en vivo, y la prueba de iotop se volvió a ejecutar: no había E / S de disco elevado . Los servicios se reiniciaron en 3 lotes, dejando php-fpm hasta el final. Después de cada lote de reinicios, la prueba de iotop confirmó que no había ningún problema. Una vez que se inició php-fpm, el problema volvió. (Hubiera sido bastante fácil simular algunas solicitudes PHP en el servidor de prueba, pero en este punto, no estaba seguro de que en realidad fuera PHP).

Desafortunadamente, el servidor sería bastante inútil sin PHP, por lo que esta no fue una conclusión ideal. Sin embargo, dado que flush-202parecía sugerir algo relacionado con la memoria (a pesar de tener suficiente memoria libre), decidí desactivar APC. Volver a ejecutar la prueba de iotop mostró que los niveles de E / S del disco eran normales. Una mirada más cercana al asunto mostró que mmap estaba habilitado y que apc.mmap_file_maskestaba configurado en /tmp/apc.XXXXXX(el valor predeterminado para esta instalación). Esa ruta configura APC para usar mmap respaldado por archivos. Simplemente comentar esta línea (por lo tanto, usando la memoria anónima predeterminada respaldada) y volver a ejecutar la prueba de iotop mostró que el problema se resolvió.

Todavía no sé por qué ninguno de los diagnósticos ejecutados no identificó las escrituras que provienen de php y que van a los archivos apc en el directorio / tmp. lsofSin embargo, la única prueba que incluso mencionó el directorio / tmp fue que los archivos que enumeraba no existían.