Plots2: Investigação de problemas de memória (vazamento?)

Observando o comentário de @icarito :

Eu me pergunto jywarren porque eu editei docker-compose-production.yml para usar menos processos (não fiz um PR para isso). Então, pode ser que nós simplesmente o ajustamos dessa maneira.

E este gráfico:

Também estamos vendo muitos erros de teste de SMTP:

Link: | https://intelligence.rackspace.com/cloud/entities/en45StuOyk/checks/chXoX9GHhF/alarm/alycd3HZyu

Sim, a carga também está muito alta. De htop e especialmente iotop parece que mailman é bastante ativo. É o culpado com certeza! Antes de 22 de maio, nós o executamos algumas vezes por dia - se pudermos executá-lo a cada poucos minutos ou mais (não a cada segundo!) - estaria tudo bem!

I, [2019-05-07T23:56:44.702410 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-08T21:33:03.762360 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-09T07:47:27.518491 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-09T08:18:47.825703 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-10T08:14:53.010705 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-10T21:45:50.739207 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-11T17:38:51.647335 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-13T03:33:15.682877 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-14T05:51:40.603184 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-14T05:53:20.857041 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-14T05:55:00.356772 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-14T05:56:40.487219 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-15T01:43:42.908744 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-16T10:13:45.703985 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-18T12:57:16.194957 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:49:27.019569 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:49:55.827419 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:50:18.722700 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:50:41.709075 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:51:00.124271 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:51:17.146210 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:51:33.745494 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:51:51.387282 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:52:09.145006 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:52:31.266559 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:53:03.176998 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:53:26.991989 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:53:54.074275 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:54:13.905343 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:54:37.736641 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:54:57.357057 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:55:15.522535 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:55:34.343241 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:55:51.964241 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:56:10.016964 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:56:42.822692 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:56:59.826809 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:57:16.178517 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:57:35.871196 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:57:59.731422 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:58:16.353160 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:58:33.608591 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:58:50.037296 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:59:06.912680 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:59:32.287362 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:59:59.201948 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:00:18.739067 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:00:42.144910 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:01:03.495556 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:01:20.493712 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:01:37.089192 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:01:53.921571 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:02:14.509227 #1]  INFO -- : Mailman v0.7.0 started

O registro é preenchido com ciclos destes, nenhum erro:

I, [2019-06-02T02:35:26.270644 #1]  INFO -- : Mailman v0.7.0 started
I, [2019-06-02T02:35:26.270851 #1]  INFO -- : Rails root found in ., requiring environment...
I, [2019-06-02T02:35:56.930267 #1]  INFO -- : POP3 receiver enabled ([email protected]@pop.gmail.com).
I, [2019-06-02T02:35:56.938850 #1]  INFO -- : Polling enabled. Checking every 5 seconds.

Parece que o mailman está travando e sendo reaparecido imediatamente!

icarito@rs-plots2:/srv/plots_container/plots2$ docker ps
CONTAINER ID        IMAGE                COMMANDCREATED             STATUS              PORTS NAMES
8d13c675568e        containers_mailman   "script/mailman_serv…"4 days ago          Up 14 seconds containers_mailman_1
f423dec91ebe        containers_web       "/bin/bash -c 'sleep…"4 days ago          Up 4 days           127.0.0.1:4001->4001/tcp containers_web_1
24f7b43efebc        containers_sidekiq   "bundle exec sidekiq…"4 days ago          Up 4 days containers_sidekiq_1
070511ab43d1        redis:latest         "docker-entrypoint.s…"4 days ago          Up 4 days           6379/tcp containers_redis_1
6ea8f0498b2c        mariadb:10.2         "docker-entrypoint.s…"4 days ago          Up 3 days           3306/tcp containers_db_1

Decidi interromper este contêiner esta noite para monitorar o efeito no desempenho.

Acho que também podemos ver quais gems updatea foram mescladas nos dias que antecederam a publicação deste código. Obrigado!

Isso é tão estranho sobre o mailman, vou olhar a configuração, mas não me lembro de nenhuma mudança na taxa.

Oh você sabe o quê? Nós o configuramos para tentar novamente 3 vezes. Talvez eles estejam se sobrepondo agora? Ele poderia pelo menos ter aumentado a taxa de tentativas, uma vez que ele tenta novamente 3 vezes para cada execução programada.

https://github.com/publiclab/plots2/blob/faf66c0b15473add33c10c47d57a6e7cc46ea669/script/mailman_server#L32

Ok modificou por 20 segundos, o que deve significar no máximo uma nova tentativa a cada 5 segundos -

https://github.com/publiclab/plots2/commit/a40ea5650f2ce9ec80ee2324cea2d8c9bd98e382

Essa será a mesma taxa de antes, quando adicionamos novas tentativas.

OK, agora trabalhando na análise após algumas horas:

https://oss.skylight.io/app/applications/GZDPChmcfm1Q/1559574420/6h/endpoints

O geral parece bom. Mas, olhando mais de perto, está aumentando o tempo de carregamento:

Comparando a última parte, onde está começando a subir:

para o anterior logo após a reinicialização:

E então, algumas semanas atrás, antes de todos os nossos problemas:

Então, finalmente, logo depois que começamos a ver problemas nos dias 22 e 23 de maio:

No geral, não é conclusivo.

Recursos:

• uma lista de joias e versões com vazamento de memória: https://github.com/ASoftCo/leaky-gems
• https://samsaffron.com/archive/2015/03/31/debugging-memory-leaks-in-ruby

Uma das coisas difíceis sobre isso é que é exatamente onde esses dois commits aconteceram:

1. desativando o cache em perfis (que posteriormente revertemos): https://github.com/publiclab/plots2/commit/794df370264a605935483aa8d0e4946bfd14c37c
2. a alteração do processo de construção do contêiner: https://github.com/publiclab/plots2/commit/794df370264a605935483aa8d0e4946bfd14c37c

Gostaria de pensar que está relacionado à adição do código retry 3 times em https://github.com/publiclab/plots2/commit/2bc7b498ef3a05bc090ef26f316a30ec0104bcc6 , que tentei ajustar hoje. Mas, na verdade, os tempos de carregamento ainda estão crescendo lentamente.

Isso pode significar que a) algo mais o está conduzindo ou b) o próprio ciclo de "recuperação / nova tentativa" pode estar causando o acúmulo de vazamento de memória?

devo comentar o código de resgate / nova tentativa inteiramente?

talvez a suspensão de espera pelo mysql para pegar está realmente ocupando threads?

Vou tentar isso. O site quase não responde.

Removi retry aqui: https://github.com/publiclab/plots2/commit/faa5a12e86bf7944dca43134f649947f03ca96a6

Implantando ... vai demorar um pouco.

Hmm, realmente não parece resolvido ... https://oss.skylight.io/app/applications/GZDPChmcfm1Q/1559577660/8h13m/endpoints

Ok, eu me pergunto se a configuração do container afetou de alguma forma o container mailman? Porque neste ponto nós revertemos todas as coisas prováveis ​​do script do mailman.

OK, durante a noite atingiu o pico e diminuiu um pouco. Mas nossos problemas ainda são bastante elevados, com picos em cerca de 20 segundos:

As chamadas de intervalo de estatísticas estão levando mais de 40 segundos!

Eles também estão demorando uma eternidade na geração de cache:

Podemos estar vendo um problema com o cache de leitura / gravação?

@icarito pode haver um problema no io de leitura / gravação ou algo na geração de cache? Só não sei por que demoraria tanto para empacotar todos os dados no cache.

Gemas vazando - verifique se estamos bem

• [x] celulóide> 0,16,0, <0,17,2
• [x] csspool <4.0.3
• [x] uva <0,2,5
• [x] oj <2.12.4
• [x] tapete vermelho <3.3.3
• [x] redis = 3.3.0
• [x] sidekiq <3.5.1
• [x] estatística lateral
• [x] terubiracer <0,12,2
• [x] zipruby <= 0.3.6

Sem vazamento, mas problemas de memória em qualquer caso:

• [x] activeadmin
• [x] axlsx
• [x] delayed_job> = 4,06
• [x] libxml-ruby <2.9.0 com Nokogiri RC3
• [x] newrelic_rpm> = 3.9.4, <= 3.9.7
• [x] sequela> = 2.12.0
• [x] pisoteio <= 1.3.5

Ainda estou vendo esse tempo massivo de geração de cache para stats_controller#range e me perguntando se precisamos ajustar onde o cache é armazenado. Parece que o padrão é o armazenamento de arquivos (e eu verifiquei, temos arquivos de cache em /plots2/tmp/cache/ . Será que seríamos ajudados mudando para o cache na memória ou memcached , ambos os quais são mudanças aparentemente muito simples?

https://guides.rubyonrails.org/v3.2/caching_with_rails.html#activesupport -cache-memorystore

Também olhando para https://www.skylight.io/support/performance-tips

Vou olhar a configuração do e-mail agora, mas se não resultar em nada, mesclarei isso, desligando o loop begin/rescue : # 5840

OK, nosso próximo passo para https://github.com/publiclab/plots2/pull/5841 é desenvolver uma estratégia de monitoramento para se o mailman cair.

Implantando com as novas credenciais de e-mail E a remoção de begin/rescue . No entanto, acho que vale a pena reimplantar com begin/rescue reinstalado se o vazamento de memória for resolvido, porque podem ter sido os problemas de credencial de e-mail.

Último erro:

mailman_1 | /app/app/models/comment.rb:265:in add_comment': undefined methodbody' for nil:NilClass (NoMethodError) mailman_1 | from /app/app/models/comment.rb:218:in receive_mail' mailman_1 | from script/mailman_server:31:inblock (2 levels) in <main>' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/router.rb:66:in instance_exec' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/router.rb:66:inroute' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/message_processor.rb:23:in block in process' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/middleware.rb:33:inblock in run' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/middleware.rb:38:in run' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/message_processor.rb:22:inprocess' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/receiver/pop3.rb:43:in block in get_messages' mailman_1 | from /usr/local/lib/ruby/2.4.0/net/pop.rb:666:ineach' mailman_1 | from /usr/local/lib/ruby/2.4.0/net/pop.rb:666:in each_mail' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/receiver/pop3.rb:42:inget_messages' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/application.rb:133:in block in polling_loop' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/application.rb:130:inloop' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/application.rb:130:in polling_loop' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/application.rb:83:inrun' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/application.rb:11:in run' mailman_1 | from script/mailman_server:22:in<main>'

É aqui:

https://github.com/publiclab/plots2/blob/e62bb49e30df79a9ddca5300579b80ff0903e3f4/app/models/comment.rb#L265

Corrigido isso! https://github.com/publiclab/plots2/commit/c02b5600fa512108d44b9163f44764a9552bbb73

ug, finalmente relal publicando a correção comment.rb ....

OK, estamos esperando para ver se a fila de e-mail diminui e veremos algum retorno à normalidade então ...

Deixei um comentário em https://publiclab.org/notes/mimiss/06-04-2019/workshop-viii para testar

Olá @jywarren , dei uma segunda olhada e tenho uma teoria.

Primeiro, aqui está um gráfico para uso de RAM nos últimos 3 meses:

É aparente a partir deste gráfico que temos aumentado o consumo de memória nos últimos três meses!

Voltei um ano inteiro:

Aparentemente, em 2019, nosso aplicativo aumentou bastante os requisitos de memória.

A teoria é que seguindo a trajetória de consumo de memória que estamos tendo, podemos ter atingido um limite em que consumimos RAM disponível e começamos a contar com a Swap, que está reduzindo a velocidade das coisas consideravelmente.

O aumento de memória pode muito bem ser do tamanho de algumas de nossas mesas ( rusers que estou olhando). Isso pode ter uma relação com # 5524.

Teremos que implementar algumas otimizações, migrar o banco de dados para um host diferente ou adicionar mais RAM.

Limpar o banco de dados de usuários de spam também é altamente recomendado.

Ainda estou inclinado para o esgotamento da memória devido ao crescimento do aplicativo / site, que está causando uma alta carga de E / S devido à "thrashing" da memória de troca para o disco.
Verifiquei nosso passenger-memory-stats do contêiner da web e acho que podemos reduzir ainda mais o pool de processos:

Vou tentar isso como um primeiro passo para remediar o desempenho.

Descobri que em fevereiro de 2018 calculamos que poderíamos executar 11 processos (porque nosso aplicativo levou 500 MB para ser executado).
A fórmula é:

max_app_processes = (TOTAL_RAM * 0.75) / RAM_PER_PROCESS
                  = 6000Mb / 750Mb
                  = 8

mas também estamos executando o Skylightd, além de um processo para buscar comentários de tweet, além do Sidekick, e também queremos executar o processo mailman.
A maior parte do uso de RAM está no contêiner da web:

De ambas as imagens acima, deduzo que ainda podemos dispensar um processo, especialmente se isso tornar as respostas mais rápidas.

Mudando para o tamanho de pool de 4 processos.

Primeira otimização feita.
Promissores primeiros 30 minutos!

Ooh!

Sábado, 8 de junho de 2019, 20:47 Sebastian Silva [email protected]
escrevi:

Primeira otimização feita.
Promissores primeiros 30 minutos!
[imagem: imagen]
https://user-images.githubusercontent.com/199755/59154753-46635b00-8a3f-11e9-87b7-51e660e4a148.png

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J7GXQIQPVWFTWGYJRLPZR4KJA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXIC5AQ#issuecomment-500182658 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAAF6J65RCLAEFO6H6RJLSTPZR4KJANCNFSM4HSA3N3Q
.

OK, então a lista de atenuações seria:

• [x] reduzir o pool de processos
• [] mover banco de dados para solução de banco de dados em nuvem do google
• [] reduzir rusers - talvez aproveitando o trabalho em https://github.com/publiclab/plots2/issues/5450
• [] mude para memcached

Olá @jywarren e @icarito ,

Primeiro, (e digo isso sem brincar): este tópico acabou sendo uma boa leitura. Ele tinha todos os elementos, um mistério, uma caça, becos sem saída, ligações fechadas, etc.

Qualquer maneira.

Em relação à tabela de rusers relativa a # 5450 e # 5524, houve um _ enorme _ agrupamento em rusers que ocorreu entre 26/04/13 - 01/01/14.

26/04/2013: 1366934400
01/01/2014: 1388534400
Intervalo UID: 59627 - 420114
Usuários: 360466

Você deseja tentar a primeira consulta do teste executado em # 5450 em uma parte desse grupo?

usuários que não postaram nenhum nó, comentário, curtida ou inscrição e nunca fizeram login

Como você disse, essa seria uma consulta fácil, já que não efetuar login abrangeria todos os critérios anteriores.

Para referência sobre o tamanho da porção equivalente aos seus últimos 6 meses propostos no outro e-mail: No mês passado, marcamos cerca de 250 postagens pela primeira vez como spam. Então, digamos que nos últimos 6 meses tivemos aproximadamente 1.500 usuários banidos devido a spam.

Ah, e acho que isso traz um bom ponto. Se você quiser se livrar dos usuários de spam, basta localizar todos os usuários que possuem conteúdo marcado como spam e, em seguida, excluir os usuários que os postaram.

Como foi mencionado brevemente em um dos problemas, pode ser bom ter usuários com conteúdo pela primeira vez marcado como spam imediatamente excluídos do banco de dados.

Olá @skilfullycurled, obrigado por sua contribuição! Portanto, a maioria dos rusers é de 2013-2014: Isso significa para mim que, embora possa ajudar a reduzir o uso de RAM, na verdade, nossas principais tabelas são rsessions e impressions .

rsessions é superior a 30 GB.
@jywarren e @skilfullycurled - seria ótimo criar uma estratégia para reduzir isso e / ou otimizar as consultas usando esta tabela!

Além disso, acho que o memcached não é uma boa opção para esse problema, pois deve consumir mais memória, não menos.

Embora seja possível limitar o uso de memória do memcached, ainda tentarei!

Não, dos documentos acima:

Se você estiver executando vários processos de servidor Ruby on Rails (que é o caso se você estiver usando mongrel_cluster ou Phusion Passenger), então suas instâncias de processo de servidor Rails não serão capazes de compartilhar dados de cache umas com as outras. Esse armazenamento de cache não é apropriado para grandes implantações de aplicativos, mas pode funcionar bem para sites pequenos e de baixo tráfego com apenas alguns processos de servidor ou para ambientes de desenvolvimento e teste.

Parece que não é muito difícil resolver _rsessões_:
https://stackoverflow.com/questions/10088619/how-to-clear-rails-sessions-table

@jywarren vamos fazer isso!

@icarito , não tenho certeza se isso já foi feito, mas eu tive acesso ao banco de dados em 2016 e notifiquei a todos que as sessões de usuário ocuparam mais espaço do que o restante do banco de dados

Para dar uma sensação, em 2016, o banco de dados de plotagens _comprimido_ como bz2 tinha 1,9 GB (agora não há tempo para descompactar para o tamanho real), _descompactado_, com as sessões removidas, tinha 518 MB

Obrigado @skilfullycurled !!! Acho que me lembro da sua entrada de 2016, não sei como deixamos de liberar isso, mas nossos despejos de banco de dados hoje são mais de 8 GB compactados, provavelmente principalmente sessões.
Vou aguardar a confirmação de @jywarren - gostaria de executar o seguinte na produção hoje e então podemos transformá-lo em uma tarefa rake ou um cron job:

EXCLUIR DAS sessões ONDE atualizadas_at <DATE_SUB (AGORA (), INTERVALO 1 DIA);

Fiquei muito curioso, o arquivo descompactado é de 6,8 GB, então menos os 518 MB que nos colocam em 6,3 GB. 😆

As rsessions são, na verdade, meu conjunto de dados favorito que tenho. É completamente _não_de_utilização, mas adoro que seja tão grande, senão maior, que os conjuntos de dados que tenho e que são _gudos_! Se alguém tiver alguma ideia sobre o que fazer com ele, me avise!

icarito ( @icarito : matrix.org) obteve aqui https://stackoverflow.com/questions/10088619/how-to-clear-rails-sessions-table
icarito ( @icarito : matrix.org) ele deve desconectar todas as sessões que 'não estiveram ativas no último dia ou semana - podemos ajustá-lo

Apenas fazendo anotações aqui. Parece bom.

Instável parece demorar muito ... pode tentar

EXCLUIR ... DE ... ONDE ... LIMIT x

E execute quantas vezes forem necessárias na produção.

Após 7 horas, isso ainda está em andamento na preparação. Obviamente, não é assim que queremos fazer isso na produção em um único lote. Outra coisa é que após a exclusão, a tabela ficará fragmentada e o tamanho do arquivo não diminuirá para a tabela de rsessions . A tabela precisa ser despejada e recriada para liberar recursos do servidor.

Meu plano para fazer isso é o seguinte:

• [] Tabela de rsessions de dump do Mysql com where updated_at > DATE_SUB(NOW(), INTERVAL 7 DAY)
• [] Renomear tabela de sessões
• [] Carregar dados limpos da tabela despejada para a nova tabela rsessions
• [] Abandone a tabela de sessões antigas

Vou tentar isso na instância de teste de stable .

Ok, incrível Sebastian e eu acho que isso pode ter
implicações para as melhorias esperadas em nosso desempenho de banco de dados após isso
a mitigação está completa, se mesmo a limpeza desta tabela pode demorar tanto ...

Na segunda-feira, 17 de junho de 2019, 21:50 Sebastian Silva [email protected]
escrevi:

Vou tentar isso em uma instância de teste estável.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6JYXKGLL2V7TV7OMNNDP3A5NVA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODX45TEI#issuecomment-502913425 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAAF6J7KQJ4OXJCRONW5G73P3A5NVANCNFSM4HSA3N3Q
.

Trazendo @cesswairimu para que ela possa tentar sua consulta no stable novamente quando o @icarito terminar. Isso deve nos dizer se os problemas em # 5917 estão relacionados apenas a # 5490 (que foi corrigido) ou se eles também estão relacionados a # 5524.

unstable ainda está excluindo ...

Deixando algumas notas aqui ao fazer testes na instância estável de teste

• [x] Tabela rsessions de dump do Mysql com where updated_at> DATE_SUB (NOW (), INTERVAL 7 DAY)
  
  
  
  • comando: root<strong i="13">@tycho</strong>:/srv/plots_staging/plots2# time docker-compose exec db bash -c "mysqldump --databases plots --tables rsessions --where='updated_at > DATE_SUB(NOW(), INTERVAL 7 DAY)' -h 127.0.0.1 -u plots --password=plots" > /tmp/rsessions.sql
  
  
  • tempo: 13 s
  
  
• [x] Renomear tabela de sessões
  
  
  
  • sintaxe: MariaDB [plots]> rename table rsessions to rsessions_prob
  
  
  • relatórios de sentinela Mysql2::Error: Table 'plots.rsessions' doesn't exist: SELECT rsessions .* FROM rsessions WHER...
  
  
  • página inicial vai para 500
  
  
• [x] Carregar dados limpos da tabela despejada para a nova tabela rsessions
  
  
  
  • sintaxe: root<strong i="38">@tycho</strong>:/srv/plots_staging/plots2# time cat /tmp/rsessions.sql | docker-comp ose exec -T db bash -c "mysql -h 127.0.0.1 -u plots plots --password=plots"
  
  
  • tempo: 7 s
  
  
  • cria um novo arquivo de tabela de rsessions (13 MB para teste!)
  
  
  • restaura a página inicial
  
  
• [x] Abandone a tabela de sessões antigas:
  
  
  
  • MariaDB [plots]> drop table rsessions_prob; Query OK, 0 rows affected (2.75 sec)
  
  

Https://stable.publiclab.org testado para fazer o login ..

Estou pronto para experimentar isso em produção!

unstable ainda está excluindo ...

Fazendo operação no banco de dados de produção ao vivo:

• [x] Tabela rsessions de dump do Mysql com where updated_at> DATE_SUB (NOW (), INTERVAL 7 DAY)
  
  
  
  • tempo: 48 s
  
  
  • tamanho de despejo: 143Mb
  
  
• [x] Renomear tabela de sessões
  
  
  
  • tempo: 11 s
  
  
  • a página inicial ficou inativa por 15 minutos às 6h UTC
  
  
• [x] Carregar dados limpos da tabela despejada para a nova tabela rsessions
  
  
  
  • cria um novo arquivo de tabela de rsessions (220 Mb)
  
  
  • restaura a página inicial
  
  
• [x] Abandone a tabela de sessões antigas:
  
  
  
  • MariaDB [plots]> drop table rsessions_prob; Query OK, 0 rows affected (43.39 sec)
  
  
  • Liberado ~ 29 GB.
  
  

Https://publiclab.org testado - a sessão foi mantida!
: tada:

mitigação feita! Esperançosamente, isso nos libertará!

vou deixar para esta noite, o site parece rápido para mim ...: stick_out_tongue_closed_eyes: espero que seja isso!

OK, então a lista de atenuações seria:

• [x] reduzir o pool de processos

• [] mover banco de dados para solução de banco de dados em nuvem do google

• [x] reduzir rsessions

• [] mude para memcached

Hmm, foi muito rápido esta manhã, mas no geral não vejo uma grande diferença! 😞

Nooooooooooooo! Bem, há apenas uma outra explicação: fantasmas. Vou abrir outra edição e procurar encontrar uma joia de exorcista ou caça-fantasmas.

Acho que na verdade houve uma melhoria no uso de E / S porque usar uma tabela de 30 GB é pesado - se você olhar de perto, os picos parecem relacionados ao Statscontroller ... talvez possamos fazer o trabalho de estatísticas no teste? Posso fazê-lo copiar o banco de dados de produção regularmente, digamos semanalmente?

Olá @icarito , gostaria de saber se você poderia responder a algumas perguntas "educacionais" para mim:

se você olhar de perto, os picos parecem relacionados ao Statscontroller ...

Por que isso seria? Devido ao cache? Só consigo pensar em três pessoas que o estariam usando, sou uma delas e não tenho usado.

talvez pudéssemos fazer o trabalho de estatísticas na encenação?

Tenho ouvido ... er ... vendo você usar muito a palavra "encenação" ultimamente. O que é isso e como isso se aplica ao site / fluxo de trabalho? Se for parte dos documentos, diga-me qual deles e tentarei entender primeiro.

Posso fazê-lo copiar o banco de dados de produção regularmente, digamos semanalmente?

Eu acho que isso seria bom. Não é tanto que os dados mais recentes sejam importantes, mas entre o sistema de perguntas e respostas que está sendo alterado e a recente migração de tags, suponho que semanalmente seja uma boa ideia, uma vez que irá capturar quaisquer mudanças estruturais assim que elas chegarem. @Cesswairimu , o que você acha ?

Este foi um tópico realmente incrível de se ler. Sim, é uma ótima ideia ter as estatísticas no estágio e copiar semanalmente também é bom: +1:
Eu pensei em fazer no futuro as consultas de estatísticas em um script que cria um modo de exibição sql e é excluído e recriado diariamente / ou semanalmente por um trabalho e talvez isso também possa ficar no palco. Gostaria de ouvir sua opinião sobre isso e se isso pode ajudar o vazamento de memória de alguma forma.

Olá @icarito , podemos aumentar a RAM do servidor? Talvez isso ajude a acelerar o site até que melhoremos nossa taxa de resposta à consulta?

Obrigado!

Obrigado por suas respostas! Agradeço o trabalho que vocês estão realizando e por responder a esta questão e ler nossos esforços! Não quero soar acusador nem nada! Estou apenas olhando os dados e tentando melhorar a confiabilidade do nosso site.
Por exemplo, tivemos um pico esta manhã: https://www.skylight.io/app/applications/GZDPChmcfm1Q/1560920940/5m/endpoints

Também vemos picos todas as noites (6h UTC) no backup por algumas horas.

Com relação à preparação e produção, atualmente temos três instâncias:

Instância | URL | Log de construção | Área de trabalho
----------- | ------- | ------------ | -------------
| instável | https://unstable.publiclab.org/ | https://jenkins.laboratoriopublico.org/view/Staging/job/Plots-Unstable/ | https://jenkins.laboratoriopublico.org/view/Staging/job/Plots-Unstable/ws/
| estável | https://stable.publiclab.org/ | https://jenkins.laboratoriopublico.org/view/Staging/job/Plots-Stable/ | https://jenkins.laboratoriopublico.org/view/Staging/job/Plots-Stable/ws/
| produção | https://publiclab.org/ | n / a | n / D

Você está certo ao dizer que devemos fazer um trabalho melhor descrevendo este processo. Atualmente eu encontrei alguns documentos aqui https://github.com/publiclab/plots2/blob/master/doc/TESTING.md#testing -branches, mas não está claro que esses branches são construídos quando nós os empurramos.

O banco de dados é atualizado manualmente de vez em quando, mas deve ser simples automatizá-lo agora que temos despejos diários do banco de dados. Vou configurá-lo e enviar um ping para você!

Isso não significa que não devemos implementar mais soluções, depois acho que um servidor web threaded (Puma) pode ajudar!

Essa é uma boa pergunta! Estamos mudando nossa hospedagem para
novo provedor e esperávamos implantar como um cluster de contêiner no novo
provedor de hospedagem.

Uma vez que a execução em contêineres não é imediatamente trivial (porque nosso aplicativo
contêiner não é imutável) - uma alternativa para começar é que poderíamos
mova o banco de dados primeiro para liberar espaço.

Não acho que devemos aumentar nosso uso de hospedagem em nosso host atual
já que mal atingimos nossa cota permitida, mas @jywarren pode confirmar?

Obrigado pelo seu trabalho!

Em 19/06/19 11:23, Gaurav Sachdeva escreveu:
>

Olá @icarito https://github.com/icarito , podemos aumentar a RAM de
o servidor? Talvez isso ajude a acelerar o site até que
melhorar nossa taxa de resposta à consulta?

Obrigado!

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AABQYS3R6ENGBU4FYJXVNXTP3JMPBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYCM7NI#issuecomment-503631797 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AABQYS7LYPEKQ4QEANK5PRLP3JMPBANCNFSM4HSA3N3Q .

Na verdade, eu me pergunto se poderíamos aumentar temporariamente nosso carneiro naquele recipiente
até que façamos a mudança e se isso ajudasse a curto prazo. Acho que ficaríamos bem
com esse custo aumentando!

Na quarta-feira, 19 de junho de 2019, 12h59, Sebastian Silva [email protected]
escrevi:

Essa é uma boa pergunta! Estamos mudando nossa hospedagem para
novo provedor e esperávamos implantar como um cluster de contêiner no novo
provedor de hospedagem.

Uma vez que a execução em contêineres não é imediatamente trivial (porque nosso aplicativo
contêiner não é imutável) - uma alternativa para começar é que poderíamos
mova o banco de dados primeiro para liberar espaço.

Não acho que devemos aumentar nosso uso de hospedagem em nosso host atual
já que mal atingimos nossa cota permitida, mas @jywarren pode confirmar?

Obrigado pelo seu trabalho!

Em 19/06/19 11:23, Gaurav Sachdeva escreveu:
>

Olá @icarito https://github.com/icarito , podemos aumentar a RAM de
o servidor? Talvez isso ajude a acelerar o site até que
melhorar nossa taxa de resposta à consulta?

Obrigado!

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
<
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AABQYS3R6ENGBU4FYJXVNXTP3JMPBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYCM7NI#issuecomment -503631797
,
ou silenciar o tópico
<
https://github.com/notifications/unsubscribe-auth/AABQYS7LYPEKQ4QEANK5PRLP3JMPBANCNFSM4HSA3N3Q
.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J4GPT5S2JYJCMGJWP3P3JQVRA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYCQFCY#issuecomment-503644811 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAAF6J4ERAAUV6JD3HUDZKDP3JQVRANCNFSM4HSA3N3Q
.

Ah, @icarito , não, não, não senti nenhuma acusação, de

E hey, não é uma acusação totalmente infundada :) embora eu esteja me divertindo um pouco fingindo que fui incriminado e fui para a clandestinidade e tenho que provar minha inocência, mas esse é um outro roteiro no qual estou trabalhando .

Felizmente, essas acusações chocantes e infundadas; ) em ambas as partes foram esclarecidas e podemos voltar ao assunto em questão.

Pergunta relacionada: Por que o controlador de estatísticas estaria ativo se ninguém o estivesse usando ou esse é o mistério?

Em relação à encenação, obrigado pela explicação. Para ter certeza de que entendi, está dizendo ...

Vou tentar isso em uma instância de teste estável.

... intercambiável com dizer, "Vou tentar isso em stable.publiclab.org"?

Para o stable.publiclab.org P - sim! E isso é construído a partir de qualquer impulso para
a filial master - espero que ajude!

Na quarta-feira, 19 de junho de 2019 às 15:19 Benjamin Sugar [email protected]
escrevi:

Oh, @icarito https://github.com/icarito , não, não, não senti nenhum
acusação, de forma alguma. Eu li, "isso é o que está acontecendo" e eu estava apenas
dizendo "isso é estranho, por que estaria fazendo isso se ninguém estava nele ...?"
Na mesma linha, não quis dizer que a documentação era pobre.
Só que você não precisava explicar se houvesse algum.

E hey, não é uma acusação totalmente infundada :) embora eu seja
me divertindo um pouco fingindo que fui incriminado e fui
subterrâneo e tenho que provar minha inocência, mas isso é outra
roteiro em que estou trabalhando.

Felizmente, essas acusações chocantes e infundadas; ) em ambas as partes têm
foi esclarecido e podemos voltar ao assunto em questão.

Pergunta relacionada: Por que o controlador de estatísticas estaria ativo se ninguém estivesse
usando ou é esse o mistério?

Em relação à encenação, obrigado pela explicação. Para ter certeza de que tenho,
está dizendo...

Vou tentar isso em uma instância de teste estável.

... intercambiável com dizer, "Vou tentar isso em stable.publiclab.org"?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J23U74QTJEVCLT6FLDP3KBBFA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYDAD5Y#issuecomment-503710199 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAAF6J2RLJGI3ESQKZARV6DP3KBBFANCNFSM4HSA3N3Q
.

@jywarren , sim! Tenho agora. Obrigada!

Obrigado pelo esclarecimento @skilfullycurled !
É realmente um mistério por que StatsController é tão ativo?

Alguns momentos atrás, tivemos outro pico que nos derrubou por alguns minutos:

O gatilho, neste caso, foi na verdade a Pesquisa de Texto Completo.
Mas pode-se ver que mesmo nessa breve fatia de tempo (3 min), o StatsController foi chamado 21 vezes .

Acho que isso pode estar afetando significativamente nosso desempenho de linha de base. Se esse uso não for conhecido, talvez os rastreadores estejam atingindo esses pontos de extremidade? Talvez um robots.txt ou algum controle de acesso consertasse isso?

@jywarren obrigado pelo esclarecimento, irei rápido possível.

Na verdade, aqui estão os detalhes do Statscontroller para o timeslice anterior:

Devemos usar o robots.txt de todas as rotas de estatísticas? Então / stats * basicamente?

Em Qui, 20 de junho de 2019 às 12h21 Sebastian Silva [email protected]
escrevi:

Na verdade, aqui estão os detalhes do Statscontroller para o timeslice anterior:
[imagem: imagen]
https://user-images.githubusercontent.com/199755/59818278-d4b1c980-92e8-11e9-9b9e-46900a253 relevant.png

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J7GBBZKJQY6TCZMQE3P3MARXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYD6ZTY#issuecomment-503835855 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAAF6J7PGJ5YZZHPLWPIJ73P3MARXANCNFSM4HSA3N3Q
.

OK, eu fiz, e também isento / api / * - já tínhamos bloqueado / stats / range *
mas agora é tudo / stats *

https://github.com/publiclab/plots2/commit/aa93dc3465b0cbaaee41ac7bec5e690437a27f5d

Em quinta- feira , 20 de junho de 2019 às 14h45, Jeffrey Warren

Devemos usar o robots.txt de todas as rotas de estatísticas? Então / stats * basicamente?

Em Qui, 20 de junho de 2019 às 12h21 Sebastian Silva [email protected]
escrevi:

Na verdade, aqui estão os detalhes do Statscontroller para o timeslice anterior:
[imagem: imagen]
https://user-images.githubusercontent.com/199755/59818278-d4b1c980-92e8-11e9-9b9e-46900a253 relevant.png

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J7GBBZKJQY6TCZMQE3P3MARXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYD6ZTY#issuecomment-503835855 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAAF6J7PGJ5YZZHPLWPIJ73P3MARXANCNFSM4HSA3N3Q
.

Então você não acha que é o cache?

O cache é gerado pelo uso, ou seja, é gerado quando a) expira E
b) uma nova solicitação chega. Portanto, algo deve estar solicitando para o
cache para gerar ... se eu puder resolver alguns problemas não relacionados e mesclar
seus PRs, vou começar uma nova publicação para produção esta noite (caso contrário
amanhã) e podemos ver se o robots.txt ajuda em tudo?

Na quinta-feira, 20 de junho de 2019 às 4:53 PM Benjamin Sugar [email protected]
escrevi:

Então você não acha que é o cache?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6JZ5WFKAP5ZCICW67VLP3PUZBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYGSO4I#issuecomment-504178545 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAAF6J4MBMWM6WIOH6VJCY3P3PUZBANCNFSM4HSA3N3Q
.

statscontroller é chamado 5,5 vezes por minuto

via @icarito - na atualização de hoje à noite, podemos ver se as alterações do robots.txt ajudam nisso.

Ei, @jywarren , vi que o commit de atualização de

Sim, adoraria uma atualização! Não tenho certeza se peguei os dados corretos, mas aqui estão algumas imagens da claraboia de antes do commit, depois do commit e das últimas 24 horas. A linha vermelha indica quando o commit foi feito. À primeira vista, parece que a resposta é sim, mas pode não ser significativa ou posso estar interpretando os dados incorretamente.

Sim, acho que uma análise completa seria ótimo. Mas a resposta curta é que
reduzimos quase pela metade nosso tempo médio de resposta a problemas para todas as solicitações de sites
de 5,5+ a 3 ou menos. É realmente uma grande melhoria. Foi um
combinação de a) quase dobrando a RAM de 8-15 GB, b) bloqueando um marketing
bot no robots.txt, ec) bloqueá-lo nas configurações do nginx também (acho que por
Intervalo de endereços IP). A parte difícil é quanto o bot / stats_controller custou
parte dele, porque não queríamos atrasar a atualização geral do site.

O momento era:

1. robots.txt por volta das 17h às 18h ET, eu acho
2. o nginx bloqueou horas depois, depois que não tínhamos certeza de quão rápido o robots.txt foi
   lido ou respeitado
3. Expansão de memória do site de ~ 7h00 ET no sábado.

Em qualquer caso, estamos indo muito bem agora. A média de carga é <4 em vez de ~ 8,
e temos 6 em vez de 4 CPUs.

Na terça, 25 de junho de 2019 às 17:32 Benjamin Sugar [email protected]
escrevi:

Sim, adoraria uma atualização! Não tenho certeza se peguei os dados corretos, mas aqui está
algumas imagens da claraboia de antes do commit, após o commit e o
nas últimas 24 horas. A linha vermelha indica quando o commit foi feito. Olha em
a superfície como a resposta é sim, mas pode não ser significativa, ou eu
pode estar interpretando os dados incorretamente.

[imagem: robôs_txt]
https://user-images.githubusercontent.com/950291/60135129-05718300-976f-11e9-8fe7-3ca1c081abe3.png

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J6ALZMY2QMSC7TZQHDP4KFEXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYRVAIQ#issuecomment-505630754 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAAF6J4E2Z2E47A4T6OWUCDP4KFEXANCNFSM4HSA3N3Q
.

Fechando isso agora!