Pico de uso de disco durante o backup, Discourse travou feio :-(

Suporte Instalação
1

Esta manhã, por volta das 5h35, o uso de disco dos meus fóruns disparou repentinamente e eles travaram, ficando totalmente offline. Tive que redimensionar a imagem do Digital Ocean para trazê-los de volta. Ufa.

Aqui está o uso de disco nos últimos 24 horas:

image
image2050×698 35.8 KB

Pergunta: que tipo de logs ou análise post-mortem posso examinar para tentar descobrir o que diabos aconteceu?! Verifiquei os logs no painel de controle do Discourse, mas não há pistas lá… eles simplesmente terminam quando o site caiu e voltam imediatamente quando ele voltou online.

2

Eu começaria por descobrir qual diretório está causando o problema. Minha abordagem padrão é entrar em /var/discourse e executar du -h -d 1. Pegue o maior diretório, entre nele e repita o processo até encontrar o suspeito. Uma vez que você o localize, isso pode dar uma pista sobre o que está acontecendo.

3

Talvez um backup automático?

4

Sim, backups são uma fonte comum desse tipo de falha — como está o uso do disco em uma janela de 7 dias?

Note também que uploads locais estão incluídos nesses backups, então, se houve um aumento significativo em uploads por volta das 18:00, isso também aumentaria o tamanho do arquivo de backup.

5

Hmm. Tenho estado transferindo arquivos do S3 de volta para meu servidor local, mas o processo parece ser executado em tempo real, movendo apenas algumas centenas de imagens por vez (todas com cerca de ~300k cada) = ~0,1 GB por lote. Na última semana, talvez eu tenha executado o script 20 vezes, então 20 lotes = cerca de 2 GB no total de espaço em disco. O que eu tinha bastante espaço disponível.

Existe alguma chance de que, mesmo que o script pareça movê-los em tempo real (baixando-os do S3 e parecendo fazê-los upload imediatamente para o Digital Ocean), possa haver algum tipo de atraso para uma tarefa em fila que teria sido acionada às 5h30, relacionada à movimentação dessas imagens?

(Além disso: eu estava executando esses lotes manualmente até as 21h, então, até onde sei, o servidor estava apenas realizando operações normais das 21h até as 5h30, quando caiu.)

Aqui está meu uso de disco de 7 dias. Estava subindo consistentemente devido às imagens sendo importadas, mas você pode ver onde atingiu 100% às 5h30:

image
image2158×688 47.9 KB

Há algum arquivo de log que possa conter pistas sobre o que aconteceu às 5h35, além dos arquivos de log que vejo na aba ‘Logs’?

6

Hmm. Meus backups estão configurados para ir para o S3 a cada 2 dias, mas nada desde o dia 9?

image
image1694×856 73.4 KB

Visualização de ‘Backups’ do Discourse

image
image1702×744 38.3 KB

Visualização do Amazon S3

image
image1586×482 68.6 KB

Aliás, depois de ver o acima, cliquei no botão no Discourse para acionar um backup. Demorou 28 minutos e pareceu funcionar bem; agora vejo o arquivo .tar.gz tanto na visualização de backups do Discourse quanto na do Amazon S3. Então por que meus backups automáticos não estão sendo acionados?! Arggggh.

7

Estou perplexo… nenhum desses é particularmente grande:

root@x-app:/var/www/discourse# du -h -d 1

3.5M	./lib
104K	./bin
8.0K	./.tx
148M    ./public
8.0K	./.bundle
14M     ./plugins
4.3M	./db
4.0K	./log
532M	./tmp
8.9M	./spec
17M     ./config
556M	./vendor
8.0K	./images
329M	./.git
2.0M	./script
80K	    ./docs
2.5M	./test
16K	    ./.github
17M	    ./app
1.6G	.

E mesmo olhando para o espaço total em disco dentro do contêiner Docker, não está tão grande quanto antes. Eu tinha um droplet da DigitalOcean de 80 GB, e foi esse que atingiu 100%. Então, redimensionei para 160 GB, dobrando o tamanho. Em teoria, isso significa que um desses deveria estar em 50%, correto?

root@x-app:/var/www/discourse# df -h

Filesystem      Size  Used Avail Use% Mounted on
overlay         155G   58G   98G  38% /
tmpfs            64M     0   64M   0% /dev
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
shm             512M  2.6M  510M   1% /dev/shm
/dev/vda1       155G   58G   98G  38% /shared
tmpfs           3.9G     0  3.9G   0% /proc/acpi
tmpfs           3.9G     0  3.9G   0% /proc/scsi
tmpfs           3.9G     0  3.9G   0% /sys/firmware
8

Você tinha picos de quase 100% todas as noites antes — parece que este foi o que te derrubou. Acredito que os backups anteriores tenham falhado devido à falta de espaço ao criar o arquivo de backup local para enviar ao S3, mas apenas falharam, sem quebrar seu fórum. Você finalmente notou quando a falta de espaço deixou o PostgreSQL (ou o Redis, ou o que for, não é realmente importante) insatisfeito exatamente no momento certo para derrubar seu fórum.

(Com quase 100 GB de imagens no meu servidor, eu faço backups agendados do Discourse sem uploads, mas com miniaturas. Depois, faço um backup baseado em arquivos com deslocamento do diretório de backups primeiro e do diretório de uploads em segundo. Testei isso para recuperação; foi a base de uma migração de site que fiz no ano passado. Armazenar arquivos tar de 100 GB todas as noites seria loucura.)

9

Aha, então esses picos são o Discourse tentando fazer um backup! Isso esclarece algumas coisas.

Então, aqui está meu gráfico dos últimos 7 dias novamente.

image
image2158×688 47.9 KB

Talvez o que estejamos vendo seja:

  1. Várias vezes ao longo da semana passada, o Discourse tentou fazer um backup. Esse processo consome temporariamente muito espaço em disco, e cada vez que tentou, esgotou o espaço disponível, então nenhum desses backups funcionou de verdade.

  2. Então, quando tentou novamente fazer um backup ontem à noite, conseguiu avançar um pouco mais, mas, infelizmente, derrubou o site.

Isso faz algum sentido, já que o último backup bem-sucedido foi em 9 de julho. Então, ele esperou 2 dias (conforme minhas configurações) e tentou novamente em 11 de julho. Isso falhou, então ele esperou 24 horas e tentou novamente nos dias 12, 13 e na tentativa fatal no dia 14.

Se foi isso que aconteceu, eu adoraria ver:

  1. Notificações melhores do Discourse quando um backup falhar

  2. Talvez o Discourse deveria automaticamente “falhar” um backup (criando uma notificação) se, ao iniciar, houver menos de x% (10%?) de espaço livre em disco. Assim, ele nem sequer começa se o espaço em disco já estiver apertado.

Aliás, se isso realmente aconteceu, então, ao analisar o primeiro backup falho, em 11 de julho, vemos que havia cerca de 40% de espaço livre em disco (o que seria cerca de 32GB!!!), mas isso não foi suficiente para que o backup fosse concluído com sucesso. É isso mesmo?! Por que o Discourse precisaria de uma quantidade tão excessiva de espaço de trabalho/temporário ao gerar um backup?

10

Não necessariamente houve um avanço adiante na noite passada; você apenas “perdeu uma corrida” — o que acontece quando o espaço acaba depende de qual componente é afetado primeiro pelo problema.

Se ele falhar ao fazer um backup, eu esperaria que tentasse enviar uma mensagem, mas se não houver espaço em disco, pode não conseguir. :scream:

Uma porcentagem fixa não diz muito; o banco de dados pode ser minúsculo em comparação com os uploads, ou vice-versa, e há variáveis como a inclusão de miniaturas e a inclusão dos uploads. Eu consigo ver a possibilidade de uma configuração de espaço livre exigido, para que você possa ajustar conforme seu site, imagino.

Não sei como você está julgando o que é “desproporcional” — não me parece desproporcional.

11

Justo o suficiente; como você aponta, há muitas variáveis em jogo.

Ah, a maneira “correta” de fazer isso seria calcular a quantidade de espaço que o sistema acha que precisará para o backup, etc., etc. Mas, para manter tudo super simples, sim, apenas uma porcentagem fixa. Só estou pensando… se as duas opções são “seu site pode travar completamente e ficar offline” ou “aqui está uma solução rápida, embora não perfeita, para o problema”, eu escolho a última, obrigada. :wink:

E falando em agradecimentos, obrigada VOCÊ por toda a ajuda com a migração e pelas suas reflexões sobre isso. :+1:t2:

12

Estimar o espaço necessário para backups é um dos problemas difíceis na ciência da computação… É um parente distante da barra de progresso. :wink:

Sério agora, parte disso é um despejo de banco de dados, e não sei como você poderia estimá-lo com antecedência. Se você tem imagens suficientes para que o espaço se torne um problema, incluí-las em arquivos de backup provavelmente está fora da prática comum.

Geralmente, quando se trata de administração de sistemas, o monitoramento de espaço livre e a saúde dos backups têm sido um ônus administrativo, e não um ônus da aplicação. Isso faz parte do que as pessoas pagam quando contratam a CDCK para hospedar seu Discourse.

Existem muitas outras formas de ficar sem espaço. Sei que você está focado no problema que te afetou, mas o problema é mais geral, e acho que isso é normalmente tratado como sobrecarga administrativa.

13

Para não estragar a festa, mas, na verdade, ao ler as postagens, não há confirmação sólida de que o processo de backup do Discourse esteja causando o problema.

Por que não confirmar 100% que este problema é causado pelo processo de backup diário? Existem mais de um processo executando arquivos crontab diários nos hosts.

@pnoeric executou um du no sistema de arquivos /var/discourse (fora do container)?

Em suas anotações, @pnoeric escreve:

root@x-app:/var/www/discourse# du -h -d 1

Mas isso completou sem incluir o diretório compartilhado do Discourse, incluindo todos os backups e uploads! E também ignora todos os arquivos Docker (e imagens) no host (que podem crescer muito se as imagens não forem podadas ao longo do tempo).

O local correto para executar essa verificação é fora do container (não dentro do container!):

Por exemplo (fora do container):

cd /var/discourse 
/var/discourse# du -sh *
4.0K	bin
4.0K	cids
56K	containers
12K	discourse-doctor
24K	discourse-setup
164K	image
24K	launcher
4.0K	LICENSE
12K	README.md
24K	samples
8.0K	scripts
62G	shared
148K	templates

Você pode ver, neste host, o diretório shared tem 62G.

E também a partir de /var do sistema de arquivos (fora do container):

cd /var
# du -sh *
511M	cache
20K	composetest
62G	discourse
1.6G	docker
8.0K	legacy
52G	lib
4.0K	local
0	lock
4.0K	locks
5.7G	log
24K	logs
64K	mail
4.0K	opt
4.0K	registry
4.0K	shared
1.9M	spool
48K	tmp
25G	 linux_app
2.2G	www

Não estou tentando estragar a festa, mas antes de sair propondo várias “correções” para o Discourse, seria muito bom confirmar com 100% de certeza que o cron de backup do Discourse é realmente o problema.

Não tivemos nenhum problema com o processo atual de backup do Discourse e, além disso, gerenciar o sistema de arquivos no host NÃO é uma tarefa do Discourse por si só.

Aqui:

du

Filesystem     1K-blocks      Used Available Use% Mounted on
udev            32892500         0  32892500   0% /dev
tmpfs            6584232      2136   6582096   1% /run
/dev/md2       470927632 215969956 230966124  49% /
tmpfs           32921160         0  32921160   0% /dev/shm
tmpfs               5120         0      5120   0% /run/lock
tmpfs           32921160         0  32921160   0% /sys/fs/cgroup
/dev/md0          482922     75082    382906  17% /boot
/dev/sda1         244988      4636    240353   2% /boot/efi
tmpfs            6584232         0   6584232   0% /run/user/1000
overlay        470927632 215969956 230966124  49% /var/lib/docker/overlay2/0f8be368b0154285423630ad50148ee2d5fdcb357c46125eafa7374ca34ef29a/merged
shm               524288      1620    522668   1% /var/lib/docker/containers/ca7b55fc5a0c123f7b2b1234ea210aa8286a34167cba9344b7929547bd323c9b/mounts/shm
overlay        470927632 215969956 230966124  49% /var/lib/docker/overlay2/7cd7e8b5b35b496eaed68753cc995e9303499a24721062055e2f06beb07e26c8/merged
shm                65536         0     65536   0% /var/lib/docker/containers/3cc0c90c3e3a5db6692e7b5d21727fbb1c13c8e07e48e4f6d954214fc03694a9/mounts/shm
overlay        470927632 215969956 230966124  49% /var/lib/docker/overlay2/31533fdf68033eed96dab4f9df89025ea3dab172ed48b6ce6431840a8df1c8ea/merged
shm               524288         0    522668   0% /var/lib/docker/containers/631fbabedda9a430dd8204ec66fb45c7514d948025124171b960ea424e28d5d4/mounts/shm
overlay        470927632 215969956 230966124  49% /var/lib/docker/overlay2/7a3ba2223ee93bc868b52b3707799d0fd7b4ca6dcc0df29f20c2c98a53903ff1/merged
shm                65536         0     65536   0% /var/lib/docker/containers/7a145366268c8ac5543a4555dc1bfc63c1e85a654e4c793e96fc2cc2e8514388/mounts/shm
overlay        470927632 215969956 230966124  49% /var/lib/docker/overlay2/add4bdd7bd88df7a0e05dff21896d3ef796f7cf2ff9759e0bb04b1953f16cd95/merged
shm                65536         0     65536   0% /var/lib/docker/containers/123743e122089b94660a6bdd2a9e55055ad91b6f75cce4ac760f36066bcf14d0/mounts/shm
overlay        470927632 215969956 230966124  49% /var/lib/docker/overlay2/b376ff32eaac0c58463e8b99b6db9ec0da3405c3f7a9f00b5430f10e07d372b0/merged
shm               524288         0    522668   0% /var/lib/docker/containers/63c52bc571b5f0d2544417da10efc37d3957e7a38f44bc8325145e795ee29559/mounts/shm

Vamos olhar para os arquivos Docker:

# cd /var/lib
# du -sh docker
30G	docker

E nossas imagens Docker são podadas e limpas regularmente.

@bartv sugeriu corretamente começar por aqui:

Eu começaria tentando descobrir qual diretório está explodindo. Minha abordagem padrão é entrar em /var/discourse e depois executar du -h -d 1. Pegue o maior diretório, entre nele e repita até encontrar o suspeito. Uma vez que você o tenha, isso pode dar uma pista do que está acontecendo.

Isso é um bom começo, mas pode haver muitos outros lugares no sistema de arquivos do host que podem encher o sistema, incluindo Docker, arquivos core, etc.

Um gráfico mostrando um pico em porcentagem uma vez por dia não é suficiente para afirmar, com autoridade, que o processo de cron de backup do Discourse é a causa raiz. Pode ser, mas pode não ser, com base nas evidências até agora!

14

Isso é ótimo. Vou tentar tudo o que você mencionou. Obrigado.

15

Sim, isso é obviamente um backup.

Não, há confirmação suficiente: os picos ocorrem em intervalos de 2 dias, com uma exceção, e a frequência do backup está configurada para 2 dias. Experiências passadas no Meta mostraram exatamente esse modo de falha também.

Sim, esse é um plano sólido para seguir em frente. A primeira recomendação para pessoas que começam a atingir o limite de espaço em disco no seu VPS é armazenamento de uploads fora da máquina com o mecanismo S3, embora.

16

Como @pnoeric está tentando migrar fora do S3 para imagens, armazenar múltiplas cópias de todas as imagens em um backup que está no S3 não cumpriria o objetivo de migrar fora do S3. @pnoeric, isso me confunde — se você quer sair do S3, mas apenas mover uma fração dos arquivos porque armazena todas as imagens no S3 em múltiplas cópias de backup, qual é o ponto?

De qualquer forma, eu estava tentando mostrar como são as alternativas. Fazer backup é difícil, especialmente se você quiser poder restaurar a partir dele.

Eu migrei do “S3” (no meu caso, Digital Ocean Spaces) depois de ter espaço suficiente no servidor e não ter um crescimento ou tráfego extraordinário que justificasse permanecer no “S3”, mas sou uma exceção, o que provavelmente explica por que nunca recebi nenhuma revisão do meu PR que resolve a corrupção de dados na migração fora do S3. :stuck_out_tongue: Então, espero que meu regime de backup seja altamente incomum.

17

Minha situação é que tenho muitas imagens, o que significa muita largura de banda de transferência, já que as pessoas visualizam essas imagens… então, quando as imagens estavam hospedadas no Amazon S3, a conta de largura de banda foi o que realmente me derrubou. Especialmente quando percebi que poderia armazenar todas as imagens no droplet da DO e isso estaria incluído nas taxas de largura de banda/armazenamento que já pago. (Em algum momento no futuro, pode fazer sentido mover as coisas de volta para o S3, ou também pode fazer mais sentido apenas aumentar meu droplet da DO novamente, então…)

Então comecei com o S3, depois percebi meu erro. Daí minha situação atual, usando seu excelente código para migrar todas as imagens do S3 de volta para o DO.

Manter um backup completo (imagens e tudo) no S3 é uma história totalmente diferente—está em “armazenamento frio” no S3 e não é acessado a menos que haja um problema. Então, sem grandes contas de largura de banda.

Além disso: estava pensando mais sobre a situação de backup/uso de disco. Ainda mantenho que falta algo aqui. Talvez seja apenas uma mensagem de aviso ou documentação melhor. Mas meu Discourse estava usando apenas 60% do disco, e meus backups off-site estavam falhando. Algum tipo de estimativa do espaço em disco necessário, ou um aviso se não houver espaço em disco, ou algo parece ser melhor do que o que acontece agora quando não há espaço suficiente, que é: nenhum backup por vários dias, seguido de uma queda total que tirou os fóruns completamente do ar. :-\

(@riking até disse “backups são uma fonte comum desse tipo de falha.” Então instâncias do Discourse estão caindo regularmente porque backups estão falhando sem aviso de um problema potencial?)

Outra maneira de dizer isso, muito simplesmente, numa visão geral de 30.000 pés: parece um defeito de projeto se um recurso básico do software (backups automáticos) pode derrubar tudo. Especialmente quando estamos falando de um recurso que apenas usa espaço em disco para preparar o backup, nem mesmo armazená-lo no mesmo disco.

18

Não, ele quis dizer que fazer backups por meio de qualquer software em qualquer servidor pode potencialmente encher o disco e causar problemas.

19

Claro, mas é por isso que você deve colocar um CDN na frente do S3. Não sirva imagens diretamente do S3; isso vai ficar absurdamente caro :scream:. Você pode colocar um Cloudfront ou até mesmo o CloudFlare na frente do S3 com bastante facilidade. O plano gratuito do CloudFlare consegue fazer isso.

E armazená-las localmente também é um péssimo negócio; você vai precisar escalar seu VPS desnecessariamente. SSD local será muito mais caro.

20

Ah, ok, entendi.

Então, como posso saber quanto espaço em disco pode ser necessário para o Discourse preparar um backup? O software não está me informando, então talvez amanhã seja 500 GB e ele tire meu servidor Digital Ocean do ar novamente. :man_shrugging:t2: Pelo menos, se eu puder fazer algumas contas rápidas, posso tentar me manter à frente disso.

Uau, que ótima ideia. Nunca pensei nisso. Então eu aplicaria o CDN ao meu bucket da Amazon e depois instruiria o Discourse a usar o S3 para todos os ativos? (Como eu tinha antes? lol)