5,5 GB scritti quotidianamente su volume di root da 1,2 GB - 4 volte i livelli precedenti

Problema: recentemente ho rinnovato uno dei miei server, è stato testato prima dell'uso e funziona bene, tuttavia, alcuni giorni fa, ho notato circa 4 volte la solita quantità di scritture nel volume principale. Non si tratta di un problema di prestazioni: il server funziona correttamente.

Il mio rinnovamento è stato piuttosto esteso (una ricostruzione completa), quindi non ho molto da fare in termini di causa. In breve, le mie modifiche includevano:

• Aggiornamento di Linux di Amazon (dal 2011.02 al 2011.09), che ha comportato anche un passaggio da ext3 a ext4 per il volume di root
• Passare da php-fcgi a php-fpm (attualmente utilizzando tcp)
• Passando da un'impostazione di proxy inverso (nginx -> apache), solo a nginx
• Sostituzione di vsftpd con pure-ftpd
• Sostituzione di dkim-proxy con opendkim
• Sostituzione webmin con ispconfig
• Aggiunta di vernice come livello di memorizzazione nella cache per i file dinamici (eccessivo per il volume di hit ottenuti da questi siti, ma è un esperimento)
• Aggiunta di una partizione di swap

Configurazione di base:

• Il mio spazio di swap è montato sul suo volume EBS - le scritture sul volume di swap sono trascurabili - l'ho essenzialmente scartato come causa (c'è molta memoria libera - ed entrambe freee iostatmostrano un utilizzo minimo di swap).
• I miei dati (database mysql, file utente (siti Web), tutti i log (da / var / log), i file di posta e vernice sul proprio volume EBS (usando mount --bind). Il volume EBS sottostante è montato su/mnt/data
• I miei file rimanenti - applicazioni del sistema operativo e del server principale (ad esempio nginx, postfix, dovecot, ecc.) - sono l'unica cosa sul volume di root - per un totale di 1,2 GB.

La nuova installazione funziona in modo più fluido (più veloce, meno memoria, ecc.) Rispetto al vecchio sistema ed è stata stabile per 20 giorni (metà ottobre) - per quanto ne so, le scritture elevate sono esistite per tutto questo tempo .

Contrariamente a quanto mi aspetterei, ho un volume di lettura basso (le mie letture sono circa l'1,5% delle mie scritture, sia in termini di blocchi che di byte sul mio volume di root). Non ho cambiato nulla sul volume di root (ad esempio nuove installazioni, ecc.) Negli ultimi giorni, ma il volume di scrittura continua ad essere molto più alto del previsto.

Obiettivo: determinare la causa dell'aumento delle scritture nel volume principale (essenzialmente, capire se si tratta di un processo (e quale processo), del diverso file system (ext4) o di un altro problema (ad es. Memoria)).

Informazioni di sistema:

• Piattaforma: Amazon EC2 (t1.micro)
• O / S: Amazon 2011.09 Linux (derivato CentOS / RHEL)
• Kernel Linux: 2.6.35.14-97.44.amzn1.i686
• Architettura: 32 bit / i686
• Dischi: 3 volumi EBS:
  • filesystem xvdap1, root, ext4 (montato con noatime)
  • xvdf, data, filesystem xfs (montato con noatime, usrquota, grpquota)
  • xvdg, swap

I volumi di root e di dati sono istantanei una volta al giorno, tuttavia, questa dovrebbe essere un'operazione di "lettura", non di scrittura. (Inoltre, la stessa pratica è stata utilizzata sul server precedente e anche il server precedente era un t1.micro.)

I dati che mi hanno indotto a esaminare l'I / O erano nei dettagli della mia ultima fattura AWS (che aveva un I / O superiore al normale - non imprevisto, dal momento che stavo configurando questo server e installando molte cose all'inizio del mese), e successivamente alle metriche CloudWatch per i volumi EBS allegati. Arrivo alla cifra "4 volte normale" estrapolando l'attività di I / O da novembre (quando non ho modificato il server) per stimare un valore mensile e confrontandolo con l'I / O dei mesi passati quando non lavoravo sul mio server precedente. (Non ho i dati esatti di iostat dal mio server precedente). La stessa quantità di scritture è persistita fino a novembre, 170-330 MB / ora.

Informazioni di diagnostica (il tempo di attività per le seguenti uscite è di 20,6 giorni):

Metriche di Cloudwatch:

• volume di root (scrittura): 5,5 GB / giorno
• volume di root (leggi): 60 MB / giorno
• volume dati (scrittura): 400 MB / giorno
• volume di dati (letto): 85 MB / giorno
• volume di scambio (scrittura): 3 MB / giorno
• volume di scambio (leggi): 2 MB / giorno

Output di: df -h(solo per volume radice)

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

Lo spazio utilizzato non è aumentato notevolmente da quando è stato lanciato questo sistema (il che a mio avviso suggerisce che i file vengano aggiornati, non creati / aggiunti).

Output di: iostat -x(con Blk_read, Blk_wrtnaggiunto in):

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

Uscita di: 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

Per riassumere quanto sopra (ed estrapolare ai valori giornalieri) sembra, nel periodo di 10 minuti:

• [flush-202] ha scritto 26 MB = 3,6 GB / giorno
• php-fpm ha scritto 17,5 MB = 2,4 GB / giorno
• MySQL ha scritto 684 KB = 96 MB / giorno
• Varnish ha scritto 580 KB = 82 MB / giorno
• [jbd2] ha scritto 528 KB = 74 MB / giorno
• Nginx ha scritto 120 KB = 17 MB / giorno
• Il proxy IMAP ha scritto 8 KB = 1,1 MB / giorno

È interessante notare che sembrerebbe che tra [flush-202]ed php-fpmè possibile rendere conto del volume giornaliero di scritture.

Utilizzando ftop, non sono in grado di rintracciare né le scritture flusho php-fpm(ad es ftop -p php-fpm.

Almeno una parte del mio problema deriva dall'identificazione di quali processi stanno scrivendo sul volume principale. Di quelli elencati sopra, mi sarei aspettato tutto di scrivere per il volume di dati (dal momento che le directory in questione sono creare collegamenti simbolici lì) (ad esempio nginx, mysql, php-fpm, varnishdirectory puntano tutti ad un volume EBS diversa)

Credo che JBD2sia il dispositivo di blocco journaling per ext4, ed flush-202è lo sfondo delle pagine sporche. Il dirty_ratioè 20 e la dirty_background_ratioè 10. memoria sporco (da /proc/meminfo) era tipicamente tra 50-150kB). Dimensione pagina ( getconf PAGESIZE) è l'impostazione predefinita del sistema (4096).

Uscita di: vmstat -s | grep paged

3248858 pagine impaginate in 104625313 pagine impaginate

Uscita di: 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

Quanto sopra sembra suggerire un numero elevato di pagine pagate - tuttavia, mi aspetto che le pagine vengano scritte nella mia partizione di swap, se necessario, non nel mio volume di root. Della memoria totale, il sistema ha in genere il 35% in uso, il 10% in buffer e il 40% nella cache, il 15% inutilizzato (ovvero il 65% libero).

Uscita di: 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

vmstatvisualizza costantemente sie sovalori di 0

Uscita di: swapon -s

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

Nell'intuizione che l'I / O scrive potrebbe essere correlata alla memoria, ho disabilitato la vernice e riavviato il server. Ciò ha cambiato il mio profilo di memoria al 10% in uso, al 2% in buffer e al 20% nella cache, al 68% inutilizzato (ovvero al 90% gratuito). Tuttavia, nell'arco di 10 minuti, iotop ha dato risultati simili a quelli precedenti:

• [flush-202] ha scritto 19 MB
• php-fpm ha scritto 10 MB

Nell'ora dal riavvio, sono già stati scritti 330 MB nel volume principale con 370 KB di pagine scambiate.

Uscita di 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/

Guardando un po 'più avanti a quanto sopra, quasi tutte le scritture possono essere attribuite a un processo (sconosciuto) che è in esecuzione ogni 5 minuti e che controlla lo stato di una varietà di servizi (come chkservdsu cPanel, ma non uso cPanel, e non ha installato questo). È pari a 4 file di registro (cron, maillog, ftp, imapproxy) aggiornati durante i 10 minuti - e alcuni elementi correlati (socket postfix, connessioni pure-ftpd). Gli altri elementi sono principalmente sessioni ispconfig modificate, aggiornamenti della contabilità di sistema e tentativi di accesso al web non validi (inesistente nome_server) (registrati in / var / log / nginx).

Conclusioni e domande:

Vorrei iniziare dicendo che sono un po 'perplesso - di solito sono abbastanza accurato, ma sento che mi manca qualcosa di ovvio in questo. Chiaramente, flushe php-fpmconto della maggior parte delle scritture, tuttavia, non so perché questo potrebbe essere il caso. Innanzitutto, prendiamo php-fpm: non dovrebbe nemmeno scrivere sul volume di root. Le sue directory (sia file che registri) sono collegate a un altro volume EBS. In secondo luogo, le cose principali che php-fpm dovrebbe scrivere sono le sessioni e le cache di pagina - che sono sia piccole che piccole - certamente non dell'ordine di 1 MB / min (più come 1K / min, se quello). La maggior parte dei siti sono di sola lettura, con solo aggiornamenti occasionali. La dimensione totale di tutti i file Web modificati nell'ultimo giorno è 2,6 MB.

In secondo luogo, considerando il flush - le scritture significative da esso suggeriscono che le pagine sporche vengono spesso scaricate sul disco - ma dato che in genere ho il 65% di memoria libera e un volume EBS separato per lo spazio di swap, non posso spiegare perché questo dovrebbe influenza le scritture sul mio volume di root, specialmente nella misura in cui si sta verificando. Mi rendo conto che alcuni processi scriveranno pagine sporche nel proprio spazio di scambio (invece di utilizzare lo spazio di scambio di sistema), ma sicuramente, immediatamente dopo un riavvio con la maggior parte della mia memoria libera, non dovrei imbattermi in una quantità sostanziale di pagine sporche. Se ritieni che questa sia la causa, fammi sapere come potrei identificare quali processi stanno scrivendo nel loro spazio di swap.

È del tutto possibile che l'intera idea di pagine sporche sia semplicemente un'aringa rossa ed è completamente estranea al mio problema (spero che sia effettivamente). In tal caso, la mia unica altra idea che ci sia qualcosa di relativo al journaling ext4 che non era presente in ext3. Oltre a ciò, sono attualmente senza idee.

Aggiornamento (s):

6 nov 2011:

Imposta dirty_ratio = 10e dirty_background_ratio = 5; aggiornato con sysctl -p(confermato tramite / proc); ripetere un test iotop di 10 minuti con risultati simili (flush ha scritto 17 MB, php-fpm ha scritto 16 MB, MySQL ha scritto 1 MB e JBD2 ha scritto 0,7 MB).

mount --bindInvece ho cambiato tutti i collegamenti simbolici che ho impostato per usare . Vernice riattivata, server riavviato; ripetere un test iotop di 10 minuti con risultati simili (flush ha scritto 12,5 MB, php-fpm ha scritto 11,5 MB, Varnish ha scritto 0,5 MB, JBD2 ha scritto 0,5 MB e MySQL ha scritto 0,3 MB).

Come nell'esecuzione sopra, il mio profilo di memoria era in uso al 20%, 2% in buffer e 58% in cache, 20% inutilizzato (cioè 80% libero) Nel caso in cui la mia interpretazione della memoria libera, in questo contesto, sia difettosa, ecco l'output di free -m(questo è un t1.micro). numero totale di buffer condivisi gratuiti usati memorizzati nella cache Mem: 602 478 124 0 14 347 - / + buffer / cache: 116 486 Swap: 1023 0 1023

Alcune informazioni aggiuntive: Output di: 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)

Ho anche eseguito contemporaneamente ftop e iotop e sono stato sorpreso di notare che le voci visualizzate in iotop non sono state visualizzate in ftop. L'elenco ftop è stato filtrato su php-fpm, poiché ho potuto innescare le scritture di quel processo in modo abbastanza affidabile. Ho notato circa 2 MB di scritture per visualizzazione di pagina per php-fpm - e devo ancora capire cosa potrebbe essere possibile scrivere - qualsiasi idea sull'accertamento di ciò che viene scritto sarebbe apprezzata.

Proverò a disattivare il journaling nei prossimi giorni e vedrò se questo migliora le cose. Per il momento, però, mi trovo a chiedermi se ho un problema I / O o un problema di memoria (o entrambi) - ma non riesco a vedere il problema di memoria, se ce n'è uno.

13 nov 2011:

Dato che il file system utilizza extents, non è stato possibile montarlo come ext3, inoltre, tenta di montarlo come di sola lettura, semplicemente ha provocato il rimontaggio come read-write.

Il file system ha infatti abilitato l'inserimento nel journal (journal da 128 MB), come è evidente da quanto segue:

Uscita di: 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

Secondo quanto segue, circa 140 GB sono stati scritti su questo volume in poco meno di un mese - solo circa 5 GB / giorno.

Uscita di: 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 a cercare file aperti, ho provato a utilizzare fusersul volume principale:

Uscita di: 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

Niente di inaspettato, sfortunatamente. Nel caso in cui fosse dovuto all'hardware sottostante, ho ripristinato l'istantanea del volume di root di ieri (nulla era cambiato nell'ultimo giorno) e ho sostituito il volume di root dell'istanza con quello nuovo. Come previsto, questo non ha avuto alcun effetto sul problema.

Il mio prossimo passo sarebbe stato rimuovere il journaling, tuttavia mi sono imbattuto nella soluzione prima di arrivare a quello.

Il problema risiedeva in APC usando mmap supportato da file. Risolto un problema di I / O del disco interrotto di circa 35x - a (stimato) 150 MB / giorno (anziché 5 GB). Potrei ancora prendere in considerazione la rimozione del journal dal momento che questo sembra essere il principale contributo rimanente a questo valore, tuttavia, questo numero è abbastanza accettabile per il momento. I passi compiuti per arrivare alla conclusione APC sono riportati in una risposta, di seguito.

Dato che la causa principale sembrava essere il journaling, quello sarebbe stato il mio prossimo passo. Per rimuovere il journaling, tuttavia, avrei bisogno di collegare il volume EBS a un'altra istanza. Ho deciso di testare la procedura utilizzando un'istantanea (di un giorno), tuttavia, prima di rimuovere il journaling, ho eseguito nuovamente il test iotop di 10 minuti (sull'istanza di test). Con mia sorpresa, ho visto valori normali (cioè non elevati), e questa è stata la prima volta che flush-202non è stato nemmeno visualizzato nell'elenco. Questa era un'istanza perfettamente funzionante (ho ripristinato anche le istantanee dei miei dati) - non c'erano state modifiche al volume di root nelle 12 ore circa da quando era stata scattata. Tutti i test hanno mostrato che gli stessi processi erano in esecuzione su entrambi i server. Questo mi ha portato a credere che la causa debba essere dovuta ad alcune richieste che il server "live" sta elaborando.

Osservando le differenze tra le uscite iotop del server che mostrano il problema e il server apparentemente identico che non ha avuto problemi, le uniche differenze sono state flush-202e php-fpm. Questo mi ha fatto pensare che, anche se a lungo, forse era un problema legato alla configurazione di PHP.

Ora, questa parte non era l'ideale, ma poiché nessuno dei servizi in esecuzione sul server live avrebbe sofferto di alcuni minuti di downtime, non importava davvero. Per restringere il problema, tutti i principali servizi (postfix, dovecot, imapproxy, nginx, php-fpm, varnish, mysqld, varnishncsa) sul server live sono stati arrestati e il test iotop eseguito di nuovo - non vi era alcun I / O del disco elevato . I servizi sono stati riavviati in 3 batch, lasciando php-fpm fino alla fine. Dopo ogni lotto di riavvii, il test iotop ha confermato che non c'erano problemi. Una volta avviato php-fpm, il problema è tornato. (Sarebbe stato abbastanza facile simulare alcune richieste PHP sul server di test, ma a questo punto, non ero sicuro che fosse effettivamente PHP).

Sfortunatamente, il server sarebbe piuttosto inutile senza PHP, quindi questa non è stata una conclusione ideale. Tuttavia, poiché flush-202sembrava suggerire qualcosa relativo alla memoria (nonostante avesse ampia memoria libera), ho deciso di disabilitare APC. Rieseguire il test iotop ha mostrato che i livelli di I / O del disco erano normali. Un'analisi più approfondita della questione ha mostrato che mmap era abilitato e che apc.mmap_file_maskera impostato su /tmp/apc.XXXXXX(impostazione predefinita per questa installazione). Quel percorso imposta APC per utilizzare mmap supportato da file. Semplicemente commentando questa riga (quindi utilizzando l'impostazione predefinita - memoria anonima supportata) e rieseguendo il test iotop è emerso che il problema è stato risolto.

Ancora non so perché nessuno dei test diagnostici non abbia identificato le scritture come provenienti da php e andando ai file apc nella directory / tmp. L'unico test che ha anche menzionato la directory / tmp era lsof, tuttavia, i file elencati erano inesistenti.