2 del cron standard dovrebbero essere sempre in esecuzione?

La mia domanda si riduce a, se più magento cron: i processi run -vvv sono sempre in esecuzione e colpiscono costantemente MySql.

Sto configurando Magento 2.2.1 tramite Google Cloud e ho i 3 lavori cron standard che sono stati preimpostati tramite l'installazione di Magento in 1 clic di 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

Guardando in alto -c ci sono sempre 2 processi php.bin in esecuzione, che colpiscono costantemente MySql e lo fanno usare circa il 50% - 70% di CPU in ogni momento. Ecco un'istantanea di come appare normalmente.

 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

Ho anche cambiato i croni in modo che vengano eseguiti ogni 5 minuti, anziché i valori predefiniti ogni minuto, ma il comportamento rimane lo stesso.

La mia ultima modifica si è alternata ogni 7 minuti e 8 minuti con 2 cron: eseguire i lavori a partire da 3 e 4 minuti l'uno dall'altro, e con quel solo 1 cron job è in esecuzione alla volta con CPU 30% - 40% da MySQL.

Anche il mio sito non ha traffico in questo momento perché non l'ho ancora lanciato. Questo comportamento è normale da Magento dal momento che non c'è nulla nel sito? L'ho lasciato riposare per 12 ore senza fare nulla e quando guardo in alto il cron è ancora in esecuzione e martellare MySQL.

AGGIORNAMENTO: Ora è chiaro che il problema è solo il primo cron: eseguire il processo che sta causando problemi. Ho cambiato il 2 ° e il 3 ° elemento di nuovo a ogni minuto e ho lasciato il primo a 8 minuti e c'è solo un singolo cron in esecuzione: eseguire il processo alla volta. Dal commento qui sotto potrebbe essere un problema con le installazioni di Bitnami Magento, ma questa è la mia prima esperienza con Magento, quindi non so se questo è un comportamento previsto (spero davvero che non lo sia).

— codesmaller
fonte

Sto riscontrando problemi simili, con un'installazione di Bitnami. A partire da ora, non sono in grado di capire perché, ma quando guardo l'utilizzo della CPU nella dashboard di GCE, posso vedere che è iniziato su alcune percentuali della CPU circa 30 giorni fa. Ora lo sto esaurendo e ho aggiunto 4 x RAM e 4 x numero di vCPU per mantenere in vita il server. Invece di top, ho usato htop. Con esso vedo che ho più di dieci righe con magento cron:run -vvv. Alcuni sono stati in diretta per diversi minuti. Proverò a scoprire perché il cron non funziona come previsto.

— user5198077,

Ottengo lo stesso comportamento quando avevo il cron impostato come predefinito ogni 1 minuto. L'ho cambiato per essere eseguito ogni 7 e 8 minuti come ho descritto nella mia domanda e genera solo 1 processo, ma sembra comunque che stia facendo troppo. Sembra forse un problema con Magento Bitnami.

— codesmaller,

Sì, il passaggio a ogni 7 minuti ha reso felice il mio server. Sono passati dal 300% + utilizzo della CPU e 8 GB di RAM fino al 40% (per uno di MySQL pagato) e 1,7 GB di RAM. Esaminerò come posso attivare la registrazione completa di Cron.

— user5198077

Anche -vvv è la registrazione dettagliata massima quindi arg può essere rimosso da crontab.

— codesmaller,

Ho dato un'occhiata al grafico Operazioni su disco (I / O). Quando il server sembra "funzionare", le operazioni di lettura sono vicine allo zero, mentre le scritture sono piuttosto elevate. Ciò che accade quando il server si arresta (o smette di rispondere) è che le operazioni di lettura superano le scritture. Confrontando la mia non così sana installazione 2.2.0 Magento Bitnami con un'altra BItnami (penso ancora su 2.1.6 o 2.1.8), la lettura / scrittura sono a livelli molto bassi, meno di 2, mentre per i non-così- in salute (ma ora funziona) le letture sono inferiori a 2 ma le scritture vanno spesso oltre le 1000! : O

— user5198077

Fornire almeno una soluzione temporanea al problema, per evitare di martellare il server MySQL. Problema Git che descrive il problema

Almeno parte del problema si riduce alla tabella cron_schedule. Consiglierei di fare un select count(*) from cron_schedule;e se questo restituisce più di qualche centinaio, allora hai il problema. Per me, quella query ha restituito 208.046 su un server che era in esecuzione solo da alcune settimane.

Se hai il problema, esegui questa query per eliminare tutto in quella tabella, tranne le righe recenti delete from cron_schedule where scheduled_at < date_sub(now(), interval 1 hour);

Quindi eseguire nuovamente la query di conteggio e dovrebbe essere più bassa. Il mio è passato da 208k a 252.

Dopo aver eseguito quella query ho riportato tutti e 3 i croni standard allo standard una volta al minuto e, come per magia, tutti e 3 corrono quasi istantaneamente. Torna alla normalità per quanto posso dire.

Nel problema di github, un altro utente suggerisce di aggiungere quella query a crontab per impedire che la tabella cresca di nuovo.

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

L'ultima risposta del team Magento sulla questione è stata a settembre affermando di non poter riprodurre il problema, ma un certo numero di utenti ha risposto dicendo di provare la stessa cosa, incluso me stesso. Quindi si spera che risolvano questo problema in modo che questo hack possa essere rimosso.

EDIT: per usare quel comando sul crontab dovrai in qualche modo passare le tue credenziali a MySQL. Vedi il mio commento qui sotto se sei su una VM o un server dedicato e vuoi mettere il tuo utente / passare crontab, altrimenti dovrai impostare un file di credenziali MySQL. E puoi usare which mysqlper trovare il percorso della tua directory binaria mysql.

— codesmaller
fonte

La tua risposta ha funzionato per me, ma aggiungendo in crontab, con mysql magento-db -e "query", dove magento-db è il nome del database (nel mio caso, è bitnami_magento), funziona anche quando c'è una password per il database? Di solito accedo al database come mysql -u somename -pe quindi inserisco la password in un prompt.

— user5198077

Utilizzando il tuo motore di ricerca preferito sarà facile trovare un paio di soluzioni per questo; Ho lasciato quella parte per l'utente / pass informazioni, ma la posterò, dopo aver dato la dichiarazione di non responsabilità: non farlo sull'hosting condiviso perché sarà visibile agli altri con top -c, tra le altre cose. In tal caso, cerca come utilizzare un file di credenziali MySQL, .mycnf o qualcosa del genere. Questo è quello che ho

*/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