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
freeeiostatmostrar 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.
watch. Havia apenas alguns arquivos (17) - principalmente arquivos PID ou arquivos de bloqueio, com alguns arquivos temporários (inexistentes). watch -d -n 0.5 'lsof / | grep REG | awk '"'"'$4 ~ /.*[wu]/ { print $9}'"'"' | sort -u'