2 do cron padrão devem estar sempre em execução?

Minha pergunta se resume a, se vários processos do magento cron: run -vvv sempre estiverem rodando e atingindo o MySql constantemente.

Estou configurando o Magento 2.2.1 através do Google Cloud e tenho os 3 trabalhos cron padrão pré-configurados através da instalação do Magento em um clique do Google.

*/1 * * * * /opt/bitnami/php/bin/php /opt/bitnami/apps/magento/htdocs/bin/magento cron:run -vvv 2>&1

*/1 * * * * /opt/bitnami/php/bin/php /opt/bitnami/apps/magento/htdocs/update/cron.php 2>&1

*/1 * * * * /opt/bitnami/php/bin/php /opt/bitnami/apps/magento/htdocs/bin/magento setup:cron:run -vvv 2>&1

Olhando para o topo -c , sempre existem dois processos php.bin em execução, que atingem o MySql constantemente e fazem com que ele use entre 50% e 70% da CPU o tempo todo. Aqui está um instantâneo da aparência normal.

 PID USER      PR  NI    VIRT    RES    SHR  S   %CPU   %MEM 
19327 mysql     20   0 3872884 332876  19172 S  60.8  3.4 332:42.45 /opt/bitnami/mysql/bin/mysqld.bin --defaults-file=/opt/bitnami/mysql/my.cnf --basedir=/opt/bitnami+
26458 bitnami   20   0  679516 476444  64492 S  24.6  4.9   0:24.85 /opt/bitnami/php/bin/php.bin /opt/bitnami/apps/magento/htdocs/bin/magento cron:run -vvv
26415 bitnami   20   0  677532 475672  64588 R  23.6  4.9   1:36.11 /opt/bitnami/php/bin/php.bin /opt/bitnami/apps/magento/htdocs/bin/magento cron:run -vvv

Também alterei os crons para executar a cada 5 minutos, em vez do padrão a cada minuto, mas o comportamento permanece o mesmo.

Minha mudança mais recente foi alternada a cada 7 minutos e 8 minutos com o 2 cron: executar tarefas iniciando com 3 e 4 minutos de diferença, e com isso apenas 1 tarefa cron está sendo executada por vez com 30% a 40% da CPU do MySQL.

Meu site também não tem tráfego no momento, porque ainda não o iniciei. Esse comportamento é normal no Magento, pois não há nada acontecendo com o site? Eu deixei descansar por 12 horas sem fazer nada e, quando olho para o topo, o cron ainda está em execução e martelando o MySQL.

ATUALIZAÇÃO: Agora está claro que o problema é apenas o primeiro cron: execute o processo que está causando problemas. Mudei o segundo e o terceiro itens de volta a cada minuto e deixei o primeiro aos 8 minutos, e há apenas um único cron: processo em execução por vez. No comentário abaixo, pode haver um problema nas instalações do Bitnami Magento, mas esta é a minha primeira experiência com o Magento, portanto não sei se esse é o comportamento esperado (realmente espero que não seja).

— codesmaller
fonte

Estou tendo problemas semelhantes, com uma instalação Bitnami. No momento, não sou capaz de descobrir o porquê, mas quando olho para a utilização da CPU no painel do GCE, vejo que ele começou em algumas porcentagens da CPU há quase 30 dias. Agora, estou no máximo e adicionei 4 x RAM e 4 x número de vCPUs para manter o servidor ativo. Em vez de top, eu usei htop. Com ele eu vejo que eu tenho mais de dez linhas com magento cron:run -vvv. Alguns já está no ar há alguns minutos. Vou tentar descobrir por que o cron não está funcionando conforme o esperado.

— user5198077

O mesmo comportamento ocorre quando o cron define o padrão a cada 1 minuto. Eu mudei para rodar a cada 7 e 8 minutos, como descrevi na minha pergunta, e isso gera apenas 1 processo, mas ainda parece que está fazendo muito. Parece que talvez seja um problema de bitnami magento.

— codesmaller

Sim, mudar para cada 7 minutos fazia meu servidor feliz. Passou de 300% + utilização da CPU e 8 GB de RAM para 40% (para um dos MySQL pagos) e 1,7 GB de RAM. Investigarei como posso ativar o log completo do Cron.

— user5198077

Além disso, o -vvv é o registro detalhado máximo para que o arg possa ser removido do crontab.

— codesmaller

Eu dei uma olhada no gráfico de Operações de Disco (E / S). Quando o servidor parece estar "funcionando", as operações de leitura são próximas de zero, enquanto as gravações são bastante altas. O que acontece quando o servidor fica inoperante (ou para de responder) é que as operações de leitura passam as gravações. Comparando minha instalação não tão saudável do 2.2.0 Magento Bitnami com outro BItnami (acho que ainda no 2.1.6 ou 2.1.8), a leitura / gravação está em níveis muito baixos, inferiores a 2, enquanto no não tão saudáveis (mas agora funcionando), as leituras estão abaixo de 2, mas as gravações geralmente ultrapassam as 1.000! : O

— user5198077 11/12

Fornecendo pelo menos um trabalho temporário para solucionar o problema, para evitar martelar o servidor MySQL. Problema no Git que descreve o problema

Pelo menos parte do problema se resume à tabela cron_schedule. Eu recomendo fazer um select count(*) from cron_schedule;e se isso retornar mais do que algumas centenas, então você tem o problema. Para mim, essa consulta retornou 208.046 em um servidor em execução por apenas algumas semanas.

Se você tiver o problema, execute esta consulta para excluir tudo da tabela, exceto as linhas recentes delete from cron_schedule where scheduled_at < date_sub(now(), interval 1 hour);

Em seguida, execute a consulta de contagem novamente e ela deve ficar mais baixa. A mina passou de 208k para 252.

Depois de executar essa consulta, defino todos os três crons padrão de volta ao padrão uma vez por minuto e, como mágica, todos os três são executados quase que instantaneamente. De volta ao normal, tanto quanto eu posso dizer.

Na questão do github, outro usuário sugere adicionar essa consulta ao crontab para impedir que a tabela cresça novamente.

0 * * * * <path_to_mysql_bin_dir>/mysql <magento_db_name> -e "delete from cron_schedule where scheduled_at < date_sub(now(), interval 1 hour)"

A última resposta da equipe Magento sobre o assunto foi em setembro, dizendo que eles não podem reproduzir o problema, mas vários usuários continuaram dizendo que experimentam a mesma coisa, inclusive eu. Esperemos que eles consertem isso para que esse hack possa ser removido.

EDIT: Para usar esse comando no crontab, você precisará passar suas credenciais para o MySQL de alguma forma. Veja meu comentário abaixo se você estiver em uma VM ou servidor dedicado e quiser colocar seu usuário / passe no crontab, caso contrário, será necessário configurar um arquivo de credenciais do MySQL. E você pode usar which mysqlpara encontrar o caminho para o diretório binário do mysql.

— codesmaller
fonte

Sua resposta funcionou para mim, mas adicionando crontab, mysql magento-db -e "query"onde magento-db é o nome do banco de dados (no meu caso, é bitnami_magento), também funciona quando há uma senha para o banco de dados? Normalmente, entro no banco de dados como mysql -u somename -pe depois insiro a senha em um prompt.

— user5198077

Usando seu mecanismo de pesquisa preferido, será fácil encontrar algumas soluções para isso; Deixei essa parte para as informações de usuário / senha, mas vou publicá-la, depois de fornecer o aviso: Não faça isso em hospedagem compartilhada, pois ficará visível para outras pessoas com top -c, entre outras coisas. Nesse caso, procure como usar um arquivo de credenciais do MySQL, .mycnf ou algo parecido. Isto é o que eu tenho

*/15 * * * * <path_to_mysql_binary_dir>/mysql -u<sql_user> -p'<sql_user_pass>' <database_name> -e "delete from cron_schedule where scheduled_at < date_sub(now(), interval 1 hour)";

— codesmaller