Gravação diária de 5,5 GB no volume raiz de 1,2 GB - níveis 4 vezes anteriores

Problema: recentemente reformulei um dos meus servidores, ele foi testado antes do uso e funciona bem; no entanto, há alguns dias, notei aproximadamente 4 vezes a quantidade usual de gravações no volume raiz. Este não é um problema de desempenho - o servidor funciona bem.

Minha reforma foi bastante extensa (uma reconstrução completa), por isso não tenho muito o que fazer em termos de causa. Resumidamente, minhas alterações incluíram:

• Atualizando o Linux da Amazon (de 2011.02 para 2011.09) - o que também resultou em uma mudança de ext3 para ext4 para o volume raiz
• Mudando de php-fcgi para php-fpm (atualmente usando tcp)
• Movendo de uma configuração de proxy reverso (nginx -> apache) para somente o nginx
• Substituindo vsftpd por pure-ftpd
• Substituindo dkim-proxy por opendkim
• Substituindo webmin por ispconfig
• Adição de verniz como uma camada de armazenamento em cache para arquivos dinâmicos (exagero no volume de acessos que esses sites recebem, mas é uma experiência)
• Adicionando uma partição de troca

Configuração básica:

• Meu espaço de troca é montado em seu próprio volume EBS - as gravações para o volume de swap são insignificantes - Tenho essencialmente descontado isso como a causa (há ampla memória livre - e ambos freee iostatmostrar o uso da swap mínima).
• Meus dados (banco de dados mysql, arquivos de usuário (sites), todos os arquivos de log (de / var / log), correio e verniz em seu próprio volume EBS (usando mount --bind) .O volume subjacente EBS é montado em/mnt/data
• Meus arquivos restantes - aplicativos do sistema operacional e do servidor núcleo (por exemplo, nginx, postfix, dovecot etc.) - são a única coisa no volume raiz - um total de 1,2 GB.

A nova configuração é mais suave (mais rápida, menos memória etc.) que o sistema antigo e permanece estável por 20 dias (meados de outubro) - até onde posso dizer, as gravações elevadas existem por todo esse tempo .

Ao contrário do que eu esperava, tenho um baixo volume de leitura (minhas leituras são cerca de 1,5% das minhas gravações, tanto em termos de blocos quanto de bytes no volume raiz). Não alterei nada no volume raiz (por exemplo, novas instalações, etc.) nos últimos dias, mas o volume de gravação continua muito acima do esperado.

Objetivo: determinar a causa do aumento de gravações no volume raiz (essencialmente, descobrir se é um processo (e qual processo), o sistema de arquivos diferente (ext4) ou outro problema (por exemplo, memória).

Informação do sistema:

• Plataforma: EC2 da Amazon (t1.micro)
• O / S: Linux 2011.09 da Amazon (derivado do CentOS / RHEL)
• Kernel do Linux: 2.6.35.14-97.44.amzn1.i686
• Arquitetura: 32 bits / i686
• Discos: 3 volumes EBS:
  • xvdap1, root, sistema de arquivos ext4 (montado com noatime)
  • xvdf, data, sistema de arquivos xfs (montado com noatime, usrquota, grpquota)
  • xvdg, swap

Os volumes raiz e de dados são capturados instantaneamente uma vez por dia - no entanto, essa deve ser uma operação de 'leitura', não de gravação. (Além disso, a mesma prática foi usada no servidor anterior - e o servidor anterior também era um t1.micro.)

Os dados que me levaram a examinar a E / S estavam nos detalhes da minha última fatura da AWS (que tinha E / S acima do normal - não inesperados, desde que eu estava configurando este servidor e instalando muitas coisas no início do mês) e, posteriormente, nas métricas do CloudWatch para os volumes EBS anexados. Chego ao valor 'quatro vezes normal' extrapolando a atividade de E / S a partir de novembro (quando não alterei o servidor) para estimar um valor mensal e comparando-o com a E / S dos últimos meses, quando não estava trabalhando no meu servidor anterior. (Não tenho dados exatos do iostat do meu servidor anterior). A mesma quantidade de gravações persistiu até novembro, 170-330MB / h.

Informações de diagnóstico (o tempo de atividade para as seguintes saídas é de 20,6 dias):

Métricas do Cloudwatch:

• volume raiz (gravação): 5,5 GB / dia
• volume raiz (lido): 60MB / dia
• volume de dados (gravação): 400MB / dia
• volume de dados (lido): 85MB / dia
• volume de troca (gravação): 3MB / dia
• volume de troca (leitura): 2MB / dia

Saída de: df -h(apenas para volume raiz)

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

O espaço usado não aumentou visivelmente desde que este sistema foi iniciado (o que, para mim, sugere que os arquivos estão sendo atualizados, não criados / anexados).

Saída de: iostat -x(com Blk_read, Blk_wrtnadicionada):

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

Saída 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 o acima (e extrapolar para valores diários), parece que, durante o período de 10 minutos:

• [flush-202] gravou 26 MB = 3,6 GB / dia
• O php-fpm gravou 17,5 MB = 2,4 GB / dia
• O MySQL gravou 684KB = 96MB / dia
• O verniz gravou 580 KB = 82 MB / dia
• [jbd2] gravou 528 KB = 74 MB / dia
• O Nginx gravou 120 KB = 17 MB / dia
• O Proxy IMAP gravou 8 KB = 1,1 MB / dia

Curiosamente, parece que entre [flush-202]e php-fpmé possível explicar o volume diário de gravações.

Usando ftop, eu sou incapaz de rastrear tanto o flushou php-fpmescreve (eg ftop -p php-fpm.

Pelo menos parte do meu problema decorre da identificação de quais processos estão gravando no volume raiz. Das listadas acima, seria de esperar tudo a ser escrito para o volume de dados (uma vez que os diretórios relevantes são simbolicamente lá) (por exemplo nginx, mysql, php-fpm, varnishdiretórios apontam para um volume EBS diferente)

Eu acredito que JBD2é o dispositivo de bloco de registro em diário para ext4 e flush-202é o fluxo de segundo plano de páginas sujas. O dirty_ratioé 20 e o dirty_background_ratioé 10. A memória suja (de /proc/meminfo) estava tipicamente entre 50-150kB). Tamanho da página ( getconf PAGESIZE) é o padrão do sistema (4096).

Saída de: vmstat -s | grep paged

3248858 páginas paginadas em 104625313 páginas paginadas

Saída 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

O texto acima parece sugerir um alto número de páginas paginadas - no entanto, eu esperaria que as páginas fossem gravadas na minha partição swap, se necessário, não no meu volume raiz. Da memória total, o sistema normalmente possui 35% em uso, 10% em buffers e 40% em cache, 15% não utilizados (ou seja, 65% grátis).

Saída 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

vmstatexibe sie sovalores consistentemente de 0

Saída de: swapon -s

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

No pressentimento de que as gravações de E / S podem estar relacionadas à memória, desativei o verniz e reiniciei o servidor. Isso mudou meu perfil de memória para 10% em uso, 2% em buffers e 20% em cache, 68% não utilizados (ou seja, 90% grátis). No entanto, durante uma execução de 10 minutos, o iotop deu resultados semelhantes aos anteriormente:

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

Na hora desde a reinicialização, já havia 330 MB gravados no volume raiz com 370 mil páginas trocadas.

Saída 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/

Analisando um pouco mais o exposto, quase todas as gravações podem ser atribuídas a um processo (desconhecido) que é executado a cada 5 minutos e à verificação do status de uma variedade de serviços (como chkservdno cPanel, mas eu não uso o cPanel, e não instalou isso). Isso equivale a 4 arquivos de log (cron, maillog, ftp, imapproxy) atualizados durante os 10 minutos - e alguns itens relacionados (soquetes postfix, conexões pure-ftpd). Os outros itens são principalmente sessões ispconfig modificadas, atualizações contábeis do sistema e tentativas inválidas de acesso à Web (inexistente server_name) (registradas em / var / log / nginx).

Conclusões e perguntas:

Deixe-me começar dizendo que estou um pouco perplexo - geralmente sou bastante completo, mas sinto que estou perdendo algo óbvio nesse caso. Claramente, flushe php-fpmresponda pela maior parte das gravações, no entanto, não sei por que isso pode ser o caso. Primeiramente, vamos usar o php-fpm - ele nem deveria estar gravando no volume raiz. Seus diretórios (arquivos e logs) são vinculados a outro volume do EBS. Em segundo lugar, as coisas principais que o php-fpm deveria estar escrevendo são sessões e caches de páginas - que são poucos e pequenos - certamente não da ordem de 1 MB / min (mais como 1 KB / min, se isso). A maioria dos sites é somente leitura, com apenas atualizações ocasionais. O tamanho total de todos os arquivos da web modificados no último dia é de 2,6 MB.

Em segundo lugar, considerando a liberação - as gravações significativas sugerem que páginas sujas são frequentemente liberadas para o disco - mas, como normalmente tenho 65% de memória livre e um volume EBS separado para espaço de troca, não sei explicar por que isso afeta as gravações no meu volume raiz, especialmente na medida em que está ocorrendo. Percebo que alguns processos gravam páginas sujas em seu próprio espaço de troca (em vez de usar o espaço de troca do sistema), mas certamente, imediatamente após uma reinicialização com a grande maioria da minha memória livre, eu não deveria estar executando uma quantidade substancial de páginas sujas. Se você acredita que essa é a causa, informe-me como posso identificar quais processos estão gravando em seu próprio espaço de troca.

É perfeitamente possível que toda a idéia de páginas sujas seja simplesmente um arenque vermelho e não esteja totalmente relacionada ao meu problema (espero que seja). Se for esse o caso, minha única outra idéia de que há algo relacionado ao diário ext4 que não estava presente no ext3. Além disso, atualmente estou sem ideias.

Atualização (ões):

6 de novembro de 2011:

Definir dirty_ratio = 10e dirty_background_ratio = 5; atualizado com sysctl -p(confirmado via / proc); reran o teste de 10 minutos com resultados semelhantes (flush escreveu 17MB, php-fpm escreveu 16MB, MySQL escreveu 1MB e JBD2 escreveu 0,7MB).

Alterei todos os links simbólicos que configuro para usar mount --bind. Verniz reativado, servidor reiniciado; reran teste de 10 minutos com resultados semelhantes (flush escreveu 12,5MB, php-fpm escreveu 11,5MB, Varnish escreveu 0,5MB, JBD2 escreveu 0,5MB e MySQL escreveu 0,3MB).

Como na execução acima, meu perfil de memória estava em 20% em uso, 2% em buffers e 58% em cache, 20% sem uso (ou seja, 80% livre). Caso minha interpretação de memória livre, nesse contexto, seja falha, Aqui está a saída de free -m(este é um t1.micro). total de buffers compartilhados gratuitos usados ​​armazenados em cache Mem: 602 478 124 0 14 347 - / + buffers / cache: 116 486 Swap: 1023 0 1023

Algumas informações adicionais: Saída 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)

Também executei o ftop e o iotop simultaneamente e fiquei surpreso ao perceber que as entradas exibidas no iotop não apareciam no ftop. A lista ftop foi filtrada para php-fpm, já que eu podia disparar gravações desse processo com bastante confiabilidade. Observei cerca de 2 MB de gravações por visualização de página para php-fpm - e ainda não entendi o que poderia estar escrevendo - todas as idéias sobre como determinar o que está sendo escrito serão apreciadas.

Vou tentar desativar o diário nos próximos dias e ver se isso melhora as coisas. No momento, porém, me pergunto se tenho um problema de E / S ou um problema de memória (ou ambos) - mas estou tendo dificuldade para ver o problema de memória, se houver algum.

13 de novembro de 2011:

Como o sistema de arquivos usa extensões, não foi possível montá-lo como ext3, além disso, tentativas de montá-lo como somente leitura, simplesmente resultaram em sua remontagem como leitura-gravação.

O sistema de arquivos realmente tem o registro no diário ativado (diário de 128 MB), como é evidente a partir do seguinte:

Saída 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

De acordo com o seguinte, cerca de 140 GB foram gravados neste volume em pouco menos de um mês - apenas cerca de 5 GB / dia.

Saída 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 a procurar arquivos abertos, tentei usar fuserno volume raiz:

Saída 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, infelizmente. Com a pouca chance de ser devido ao hardware subjacente, restaurei o instantâneo do volume raiz de ontem (nada havia mudado no último dia) e substituí o volume raiz da instância pelo novo. Como esperado, isso não teve efeito no problema.

Meu próximo passo seria remover o diário, no entanto, eu me deparei com a solução antes de chegar a isso.

O problema estava na APC usando o mmap suportado por arquivo. A correção dessa entrada / saída de disco diminuiu em cerca de 35x - a (estimada) 150MB / dia (em vez de 5GB). Ainda posso considerar a remoção do diário, pois esse parece ser o principal contribuinte restante para esse valor; no entanto, esse número é aceitável por enquanto. As medidas tomadas para chegar à conclusão da APC estão publicadas em uma resposta abaixo.

Como a causa principal parecia estar registrando em diário, esse seria o meu próximo passo. Para remover o registro no diário, no entanto, eu precisaria anexar o volume EBS a outra instância. Decidi testar o procedimento usando um instantâneo (antigo), no entanto, antes de remover o registro no diário, executei novamente o teste iotop de 10 minutos (na instância de teste). Para minha surpresa, vi valores normais (ou seja, não elevados), e essa foi a primeira vez que flush-202nem apareceu na lista. Esta foi uma instância totalmente funcional (eu restaurei instantâneos dos meus dados também) - não houve alterações no volume raiz nas 12 horas mais ou menos desde que foram tiradas. Todos os testes mostraram que os mesmos processos estavam em execução nos dois servidores. Isso me levou a acreditar que a causa deve se resumir a alguns pedidos que o servidor 'ativo' está processando.

Observando as diferenças entre as saídas iotop do servidor que exibe o problema e o servidor aparentemente idêntico que não teve nenhum problema, as únicas diferenças foram flush-202e php-fpm. Isso me fez pensar que, apesar de um longo tiro, talvez fosse um problema relacionado à configuração do PHP.

Agora, essa parte não era ideal - mas como nenhum dos serviços em execução no servidor ativo sofreria alguns minutos de inatividade, isso realmente não importava. Para diminuir o problema, todos os principais serviços (postfix, dovecot, imapproxy, nginx, php-fpm, verniz, mysqld, varnishncsa) no servidor ativo foram interrompidos e a repetição do teste do iotop - não houve E / S de disco elevada . Os serviços foram reiniciados em 3 lotes, deixando o php-fpm até o final. Após cada lote de reinicializações, o teste iotop confirmou que não havia problema. Depois que o php-fpm foi iniciado, o problema retornava. (Teria sido bastante fácil simular algumas solicitações de PHP no servidor de teste, mas, neste momento, eu não tinha certeza de que era realmente PHP).

Infelizmente, o servidor não faria sentido sem o PHP, portanto essa não era uma conclusão ideal. No entanto, como flush-202parecia sugerir algo relacionado à memória (apesar de ter ampla memória livre), decidi desativar o APC. A execução do teste iotop mostrou que os níveis de E / S do disco estavam normais. Uma análise mais detalhada do assunto mostrou que o mmap estava ativado e apc.mmap_file_maskfoi definido como /tmp/apc.XXXXXX(o padrão para esta instalação). Esse caminho define a APC para usar o mmap suportado por arquivo. Simplesmente comentar esta linha (portanto, usando o padrão - memória anônima suportada) e executar novamente o teste do iotop mostraram que o problema foi resolvido.

Ainda não sei por que nenhum dos diagnósticos executados não identificou as gravações como provenientes do php e indo para os arquivos apc no diretório / tmp. O único teste que até mencionou o diretório / tmp foi lsof, no entanto, os arquivos listados por ele eram inexistentes.