Não é meu problema, mas isso significa que não há mais nada?
1 curtida
Talvez não intencionalmente, mas pode valer a pena auditar o conteúdo do host em busca de processos de mineração de criptomoedas, etc…
3 curtidas
Passo 1: corrigir o problema de desempenho já identificado no uso do driver vfs
7 curtidas
Sobre essa troca para (idealmente) overlay2, eu terei que apagar minha instalação atual e reinstalar tudo. Isso ocorre porque o host em que estou atualmente suporta apenas fuse-overlayfs ou o vfs, que não são recomendados.
No entanto, em breve eles habilitarão KVMs que suportam overlay2.
Portanto, minha intenção seria usar isso, em vez do fuse-overlayfs, que também não é sugerido.
Agora, no próprio aplicativo Discourse, posso fazer backups. O que exatamente eles fazem backup?
Eu perderia algo do fórum Discourse atual (quero dizer, mensagens, chats, configurações, usuários, imagens carregadas, etc.) se fizesse um backup, reinstalasse um Discourse novo em um servidor novo e, após a configuração inicial do Discourse, o substituísse pelo backup?
Isso funcionaria?
Sim, isso funcionaria.
A única coisa que você não mencionou é garantir que você tenha os mesmos plugins no novo Discourse que você tem no atual. Se você reutilizar seu app.yml, você também estaria bem.
3 curtidas
Certo, obrigado por apontar isso, aposto que eu teria esbarrado nisso.\n\nOk, então…\n\n1. Faça backup na área de administração do Discourse\n2. Apenas por segurança, é claro, faça backup do servidor\n3. Tire uma cópia do arquivo yaml\n4. Despeje o servidor\n5. Configure um novo servidor com tecnologia suportada\n6. Instale o Docker com o driver de armazenamento adequado\n7. Recrie uma instância completa do Discourse usando o arquivo yaml de backup\n8. Restaure o Discourse do backup\n\nUm pouco surpreso que o backup seja de apenas 19,2 MB.\nJá temos várias imagens etc. carregadas… mas acho que tudo o que posso fazer é tentar.\n\nTentarei isso no fim de semana e reportarei se a mudança do driver de armazenamento resolveu o problema.
1 curtida
Verifique se isso está definido:
1 curtida
Observe que essa configuração específica se aplica apenas a backups agendados, não a backups manuais. Com backups manuais, você sempre tem uma escolha explícita.
Outra configuração a ser habilitada é incluir miniaturas em backups
@smileBeda Eu adiaria a #4 até que tudo esteja funcionando bem.
3 curtidas
Ele realmente está marcado, mas Incluir miniaturas geradas em backups. Desativar isso tornará os backups menores, mas exigirá um novo processamento de todas as postagens após uma restauração. não estava.
@RGJ … certo, boa ideia, exigirá mais etapas, pois terei que criar um servidor sob uma nova entidade, mas é insignificante em comparação com o risco.
Deixarei o backup automatizado ser acionado para que eu obtenha todos os dados nele, pois entendo que o manual não incluiria as imagens, etc.
Obrigado…
Essa é uma suposição incorreta.
Ao criar um backup manualmente, você tem a opção em um pop-up se deseja fazer backup apenas do banco de dados ou incluir uploads.
Ao criar backups agendados, a configuração backup com uploads decide isso.
4 curtidas
Ok, interpretei mal sua declaração anterior: Por favor, observe que essa configuração específica se aplica apenas a backups agendados, não aos manuais.
Obrigado…
2 curtidas
Olá, estou reutilizando este tópico, pois ele ainda está aberto e estamos tendo o mesmo problema após a migração para um novo servidor virtual. Assim como todos dizem, nunca levei mais de 20 minutos para reconstruir nosso Discourse, mas neste novo servidor leva horas, e ele tem o dobro de recursos do anterior. 
Verifiquei outros tópicos sobre atualizações de uma hora no Meta, mas não consigo descobrir qual é o problema com o nosso:
Servidor: 4Gb RAM, 2CPU, 50 Gb disco.
Swap:
/$ free
total used free shared buff/cache available
Mem: 3911740 507208 2318476 268 1384032 3404532
Swap: 4095976 45472 4050504
Docker:
/$ sudo docker info
Client:
Version: 26.1.3
Context: default
Debug Mode: false
Server:
Containers: 3
Running: 0
Paused: 0
Stopped: 3
Images: 3
Server Version: 26.1.3
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version:
runc version:
init version:
Security Options:
apparmor
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.8.0-31-generic
Operating System: Ubuntu 24.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.731GiB
Name: podkasts
ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Parece normal para mim, mas talvez eu esteja perdendo alguma coisa. Onde mais podemos procurar?
Talvez um vizinho barulhento esteja tornando sua nova VM mais lenta do que a antiga porque ele está usando toda a CPU que você não está recebendo?
1 curtida
Sim, obrigado, é reconfortante saber que um administrador experiente como você não está vendo nada óbvio nas informações acima. E sim, estamos começando a olhar para o servidor físico e nosso “bairro” virtual. Pelo menos o fórum funciona sem problemas perceptíveis pelos usuários. Estamos enfrentando esse sério problema de desempenho apenas com reconstruções. Ontem, levamos 4 horas para reconstruir. 
1 curtida
Se eu tivesse esse problema, teria duas ou três janelas de terminal abertas. Uma para executar a reconstrução, uma para fazer anotações sobre o tempo decorrido e para anotar onde os longos atrasos estão ocorrendo entre as atualizações de log, e a última para manter um registro da atividade da máquina: provavelmente executando vmstat 5
Quando você atingir um ponto onde o log não está atualizando por um tempo suspeito, anote a atividade relatada pelo vmstat.
Publique aqui extratos adequados do log com suas anotações e a saída correspondente do vmstat.
Parece muito provável que sejam partes específicas da reconstrução que estão demorando: o que fazer é descobrir quais partes e ver o que a máquina está fazendo nesses momentos.
Eu provavelmente também tiraria um instantâneo da atividade da máquina com ps auxf durante as pausas também.
4 curtidas
Obrigado, este é um ótimo conselho. Da próxima vez que precisarmos reconstruir, faremos dessa maneira.
2 curtidas