5,5 Go écrits quotidiennement pour un volume racine de 1,2 Go - 4 fois les niveaux précédents

Problème: J'ai récemment réorganisé un de mes serveurs, il a été testé avant utilisation et fonctionne bien, cependant, il y a quelques jours, j'ai remarqué environ 4 fois la quantité habituelle d'écritures sur le volume racine. Ce n'est pas un problème de performances - le serveur fonctionne correctement.

Ma refonte a été assez importante (une reconstruction complète), donc je n'ai pas grand-chose à faire en termes de cause. En bref, mes changements comprenaient:

• Mise à niveau du Linux d'Amazon (de 2011.02 à 2011.09) - qui a également entraîné un changement d'ext3 à ext4 pour le volume racine
• Passer de php-fcgi à php-fpm (utilise actuellement tcp)
• Passer d'une configuration de proxy inverse (nginx -> apache) à nginx uniquement
• Remplacement de vsftpd par pure-ftpd
• Remplacement de dkim-proxy par opendkim
• Remplacement de webmin par ispconfig
• Ajout de vernis comme couche de mise en cache pour les fichiers dynamiques (surpuissance pour le volume de visites de ces sites, mais c'est une expérience)
• Ajout d'une partition de swap

Configuration de base:

• Mon espace de swap est monté sur son propre volume EBS - les écritures sur le volume de swap sont négligeables - j'ai essentiellement escompté cela comme cause (il y a suffisamment de mémoire libre - et les deux freeet iostatmontrent une utilisation de swap minimale).
• Mes données (base de données mysql, fichiers utilisateur (sites Web), tous les journaux (à partir de / var / log), courrier et fichiers de vernis sur leur propre volume EBS (à l'aide mount --bind). Le volume EBS sous-jacent est monté sur/mnt/data
• Mes fichiers restants - le système d'exploitation et les applications du serveur principal (par exemple nginx, postfix, pigeonnier, etc.) - sont la seule chose sur le volume racine - un total de 1,2 Go.

La nouvelle configuration est plus fluide (plus rapide, moins de mémoire, etc.) que l'ancien système et est stable depuis 20 jours (mi-octobre) - pour autant que je sache, les écritures élevées existent depuis tout ce temps .

Contrairement à ce que j'attendrais, j'ai un faible volume de lecture (mes lectures représentent environ 1,5% de mes écritures, à la fois en termes de blocs et d'octets sur mon volume racine). Je n'ai rien changé au volume racine (par exemple de nouvelles installations, etc.) au cours des derniers jours, mais le volume d'écriture continue d'être beaucoup plus élevé que prévu.

Objectif: déterminer la cause de l'augmentation des écritures sur le volume racine (essentiellement, déterminer s'il s'agit d'un processus (et de quel processus), du système de fichiers différent (ext4) ou d'un autre problème (par exemple la mémoire)).

Informations système:

• Plateforme: EC2 d'Amazon (t1.micro)
• O / S: Linux 2011.09 d'Amazon (dérivé de CentOS / RHEL)
• Noyau Linux: 2.6.35.14-97.44.amzn1.i686
• Architecture: 32 bits / i686
• Disques: 3 volumes EBS:
  • xvdap1, root, système de fichiers ext4 (monté avec noatime)
  • xvdf, data, système de fichiers xfs (monté avec noatime, usrquota, grpquota)
  • xvdg, swap

Les volumes racine et de données sont instantanés une fois par jour - cependant, cela devrait être une opération de «lecture», pas d'écriture. (De plus, la même pratique a été utilisée sur le serveur précédent - et le serveur précédent était également un t1.micro.)

Les données qui m'ont amené à examiner les E / S se trouvaient dans les détails de ma dernière facture AWS (qui avait des E / S supérieures à la normale - pas inattendu, car je configurais ce serveur et installais beaucoup de choses au début du mois), puis aux métriques CloudWatch pour les volumes EBS joints. J'arrive au chiffre «4 fois normal» en extrapolant l'activité d'E / S à partir de novembre (lorsque je n'ai pas modifié le serveur) pour estimer une valeur mensuelle et la comparer avec les E / S des mois précédents lorsque je ne travaillais pas sur mon serveur précédent. (Je n'ai pas de données iostat exactes de mon serveur précédent). La même quantité d'écritures a persisté jusqu'en novembre, 170-330 Mo / h.

Informations de diagnostic (le temps de disponibilité pour les sorties suivantes est de 20,6 jours):

Mesures Cloudwatch:

• volume racine (écriture): 5,5 Go / jour
• volume racine (lecture): 60 Mo / jour
• volume de données (écriture): 400 Mo / jour
• volume de données (lecture): 85 Mo / jour
• volume de swap (écriture): 3 Mo / jour
• volume de swap (lecture): 2 Mo / jour

Sortie de: df -h(pour le volume racine uniquement)

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

L'espace utilisé n'a pas sensiblement augmenté depuis le lancement de ce système (ce qui, selon moi, suggère que les fichiers sont en cours de mise à jour et non créés / ajoutés).

Sortie de: iostat -x(avec Blk_read, Blk_wrtnajouté):

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

Sortie 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

Pour résumer ce qui précède (et extrapoler aux valeurs quotidiennes), cela ressemble, sur la période de 10 minutes:

• [flush-202] a écrit 26 Mo = 3,6 Go / jour
• php-fpm a écrit 17,5 Mo = 2,4 Go / jour
• MySQL a écrit 684 Ko = 96 Mo / jour
• Le vernis a écrit 580 Ko = 82 Mo / jour
• [jbd2] a écrit 528 Ko = 74 Mo / jour
• Nginx a écrit 120 Ko = 17 Mo / jour
• Le proxy IMAP a écrit 8 Ko = 1,1 Mo / jour

Chose intéressante, il semblerait qu'entre [flush-202]et php-fpmil soit possible de tenir compte du volume quotidien d'écritures.

À l'aide de ftop, je suis incapable de retrouver les écritures flushou php-fpm(par exemple ftop -p php-fpm.

Au moins une partie de mon problème provient de l'identification des processus qui écrivent sur le volume racine. Parmi ceux énumérés ci - dessus, je me attends à tout écrirez au volume de données (puisque les répertoires concernés sont là un lien symbolique) (par exemple nginx, mysql, php-fpm, varnishrépertoires pointent tous vers un volume différent EBS)

Je pense que JBD2c'est le bloc de journalisation pour ext4, et flush-202c'est le fond de pages sales. La valeur dirty_ratioest 20 et la valeur dirty_background_ratio10. La mémoire sale (de /proc/meminfo) se situait généralement entre 50 et 150 Ko). La taille de la page ( getconf PAGESIZE) est la valeur par défaut du système (4096).

Sortie de: vmstat -s | grep paged

3248858 pages paginées dans 104625313 pages paginées vers l'extérieur

Sortie 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

Ce qui précède semble suggérer un nombre élevé de pages paginées - cependant, je m'attends à ce que les pages soient écrites sur ma partition de swap si nécessaire, pas sur mon volume racine. De la mémoire totale, le système utilise généralement 35%, 10% dans les tampons et 40% en cache, 15% inutilisés (c'est-à-dire 65% gratuits).

Sortie 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

vmstataffiche systématiquement siet des sovaleurs de 0

Sortie de: swapon -s

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

Sur l'intuition que les E / S écrit peut être liée à la mémoire, j'ai désactivé le vernis et redémarré le serveur. Cela a changé mon profil de mémoire à 10% en cours d'utilisation, 2% dans les tampons et 20% en cache, 68% inutilisé (c'est-à-dire 90% gratuit). Cependant, sur une période de 10 minutes, iotop a donné des résultats similaires à ceux précédemment:

• [flush-202] a écrit 19 Mo
• php-fpm a écrit 10 Mo

Dans l'heure qui a suivi le redémarrage, 330 Mo ont déjà été écrits sur le volume racine avec 370 000 pages échangées.

Sortie 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/

En regardant un peu plus loin dans ce qui précède, presque toutes les écritures peuvent être attribuées à un processus (inconnu) qui s'exécute toutes les 5 minutes et vérifie l'état d'une variété de services (comme chkservdsur cPanel, mais je n'utilise pas cPanel, et ne l'ai pas installé). Cela équivaut à 4 fichiers journaux (cron, maillog, ftp, imapproxy) mis à jour pendant les 10 minutes - et quelques éléments connexes (sockets postfix, connexions pure-ftpd). Les autres éléments sont principalement des sessions ispconfig modifiées, des mises à jour de la comptabilité système et des tentatives d'accès Web non valides (nom_serveur inexistant) (enregistrées dans / var / log / nginx).

Conclusions et questions:

Permettez-moi de commencer par dire que je suis un peu perplexe - je suis généralement assez consciencieux, mais je pense que je manque quelque chose d'évident sur celui-ci. De toute évidence, flushet php-fpmreprésentent la majeure partie des écritures, cependant, je ne sais pas pourquoi cela pourrait être le cas. Tout d'abord, prenons php-fpm - il ne devrait même pas écrire sur le volume racine. Ses répertoires (fichiers et journaux) sont liés à un autre volume EBS. Deuxièmement, les principales choses que php-fpm devrait écrire sont les sessions et les pages-caches - qui sont à la fois peu nombreuses et petites - certainement pas de l'ordre de 1 Mo / min (plus comme 1 K / min, si cela). La plupart des sites sont en lecture seule, avec seulement des mises à jour occasionnelles. La taille totale de tous les fichiers Web modifiés au cours de la dernière journée est de 2,6 Mo.

Deuxièmement, compte tenu du vidage - les écritures importantes qui en découlent me suggèrent que les pages sales sont fréquemment vidées sur le disque - mais étant donné que j'ai généralement 65% de mémoire libre et un volume EBS distinct pour l'espace d'échange, je ne peux pas expliquer pourquoi cela affecter les écritures sur mon volume racine, en particulier dans la mesure où cela se produit. Je me rends compte que certains processus écriront des pages sales dans leur propre espace de swap (au lieu d'utiliser l'espace de swap du système), mais sûrement, immédiatement après un redémarrage avec la grande majorité de ma mémoire étant libre, je ne devrais pas courir dans une quantité substantielle de pages sales. Si vous pensez que cela est la cause, veuillez me faire savoir comment identifier les processus qui écrivent dans leur propre espace de swap.

Il est tout à fait possible que toute l'idée de pages sales soit simplement un hareng rouge et soit complètement indépendante de mon problème (j'espère que c'est le cas). Si tel est le cas, ma seule autre idée qu'il y a quelque chose concernant la journalisation ext4 qui n'était pas présent dans ext3. Au-delà, je suis actuellement à court d'idées.

Mises à jour):

6 nov. 2011:

Définissez dirty_ratio = 10et dirty_background_ratio = 5; mis à jour avec sysctl -p(confirmé via / proc); relancez le test iotop de 10 minutes avec des résultats similaires (flush écrit 17 Mo, php-fpm écrit 16 Mo, MySQL écrit 1 Mo et JBD2 écrit 0,7 Mo).

J'ai changé tous les liens symboliques que j'ai configurés pour les utiliser à la mount --bindplace. Vernis réactivé, serveur redémarré; relancez le test iotop de 10 minutes avec des résultats similaires (flush a écrit 12,5 Mo, php-fpm a écrit 11,5 Mo, Varnish a écrit 0,5 Mo, JBD2 a écrit 0,5 Mo et MySQL a écrit 0,3 Mo).

Comme lors de l'exécution ci-dessus, mon profil de mémoire était de 20% utilisé, 2% dans les tampons et 58% mis en cache, 20% inutilisé (c'est-à-dire 80% gratuit) Juste au cas où mon interprétation de la mémoire libre, dans ce contexte, serait erronée, voici la sortie de free -m(c'est un t1.micro). total des tampons partagés libres mis en cache Mem: 602 478 124 0 14 347 - / + buffers / cache: 116 486 Swap: 1023 0 1023

Quelques informations supplémentaires: Sortie 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)

J'ai également exécuté ftop et iotop simultanément et j'ai été surpris de constater que les entrées apparaissant dans iotop n'apparaissaient pas dans ftop. La liste ftop a été filtrée en php-fpm, car je pouvais déclencher des écritures de ce processus de manière assez fiable. J'ai noté environ 2 Mo d'écritures par page pour php-fpm - et je n'ai pas encore compris ce qu'il pourrait éventuellement être en train d'écrire - toute idée sur la vérification de ce qui est écrit serait appréciée.

Je vais essayer de désactiver la journalisation dans les prochains jours et voir si cela améliore les choses. Pour le moment cependant, je me demande si j'ai un problème d'E / S ou un problème de mémoire (ou les deux) - mais j'ai du mal à voir le problème de mémoire, s'il y en a un.

13 nov. 2011:

Comme le système de fichiers utilise des extensions, il n'a pas été possible de le monter en tant qu'ext3. De plus, les tentatives de montage en lecture seule ont simplement entraîné son remontage en lecture-écriture.

La journalisation est en effet activée dans le système de fichiers (journal de 128 Mo), comme il ressort de ce qui suit:

Sortie 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

Selon ce qui suit, environ 140 Go ont été écrits sur ce volume en un peu moins d'un mois, soit environ 5 Go / jour.

Sortie 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

En continuant à chercher des fichiers ouverts, j'ai essayé d'utiliser fusersur le volume racine:

Sortie 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

Rien d'inattendu, malheureusement. Au cas où cela serait dû au matériel sous-jacent, j'ai restauré l'instantané du volume racine d'hier (rien n'avait changé le dernier jour) et j'ai remplacé le volume racine de l'instance par le nouveau. Comme prévu, cela n'a eu aucun effet sur le problème.

Ma prochaine étape aurait été de supprimer le journalisation, mais je suis tombé sur la solution avant d'y arriver.

Le problème résidait dans APC en utilisant mmap sauvegardé sur fichier. La correction de ces E / S de disque perdues par environ 35x - à (environ) 150 Mo / jour (au lieu de 5 Go). Je pourrais toujours envisager de supprimer le journalisation car cela semble être le principal contributeur restant à cette valeur, cependant, ce nombre est tout à fait acceptable pour le moment. Les mesures prises pour parvenir à la conclusion APC sont publiées dans une réponse ci-dessous.

Étant donné que la principale cause semblait être la journalisation, cela aurait été ma prochaine étape. Cependant, pour supprimer la journalisation, je devrais attacher le volume EBS à une autre instance. J'ai décidé de tester la procédure à l'aide d'un instantané (vieux d'un jour), mais avant de supprimer la journalisation, j'ai relancé le test iotop de 10 minutes (sur l'instance de test). À ma grande surprise, j'ai vu des valeurs normales (c'est-à-dire non élevées), et c'était la première fois qui flush-202n'apparaissait même pas sur la liste. Il s'agissait d'une instance entièrement fonctionnelle (j'ai également restauré des instantanés de mes données) - il n'y avait eu aucune modification du volume racine dans les 12 heures environ depuis qu'il avait été pris. Tous les tests ont montré que les mêmes processus s'exécutaient sur les deux serveurs. Cela m'a amené à croire que la cause devait se résumer à certaines requêtes que le serveur «live» est en train de traiter.

En regardant les différences entre les sorties iotop du serveur affichant le problème et le serveur apparemment identique qui n'a eu aucun problème, les seules différences étaient flush-202et php-fpm. Cela m'a fait penser que, bien que de loin, c'était peut-être un problème lié à la configuration PHP.

Maintenant, cette partie n'était pas idéale - mais comme aucun des services exécutés sur le serveur en direct ne souffrirait de quelques minutes d'arrêt, cela n'avait pas vraiment d'importance. Pour réduire le problème, tous les principaux services (postfix, pigeonnier, imapproxy, nginx, php-fpm, vernis, mysqld, varnishncsa) sur le serveur en direct ont été arrêtés et le test iotop a été réexécuté - il n'y avait pas d'E / S disque élevées . Les services ont été redémarrés en 3 lots, laissant php-fpm jusqu'à la fin. Après chaque lot de redémarrages, le test iotop a confirmé qu'il n'y avait aucun problème. Une fois php-fpm démarré, le problème est revenu. (Il aurait été assez facile de simuler quelques requêtes PHP sur le serveur de test, mais à ce stade, je n'étais pas sûr qu'il s'agissait en fait de PHP).

Malheureusement, le serveur serait plutôt inutile sans PHP, donc ce n'était pas une conclusion idéale. Cependant, comme flush-202semblait suggérer quelque chose concernant la mémoire (malgré une mémoire libre suffisante), j'ai décidé de désactiver APC. La réexécution du test iotop a montré que les niveaux d'E / S disque étaient normaux. Un examen plus approfondi de la question a montré que mmap était activé et qu'il apc.mmap_file_maskétait réglé sur /tmp/apc.XXXXXX(la valeur par défaut pour cette installation). Ce chemin définit APC pour utiliser mmap sauvegardé sur fichier. Le simple fait de commenter cette ligne (donc d'utiliser la valeur par défaut - mémoire anonyme sauvegardée) et de relancer le test iotop a montré que le problème était résolu.

Je ne sais toujours pas pourquoi aucun des diagnostics n'a identifié les écritures comme venant de php et allant dans les fichiers apc du répertoire / tmp. Le seul test qui mentionnait même le répertoire / tmp était lsofcependant que les fichiers qu'il listait étaient inexistants.