Doit-on toujours exécuter 2 du cron standard?

Ma question se résume à, si plusieurs cron magento: les processus run -vvv sont toujours en cours d'exécution et frappent MySql en permanence.

Je configure Magento 2.2.1 via Google Cloud et j'ai les 3 tâches cron standard qui ont été pré-configurées via l'installation en un clic de Google de Magento.

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

En regardant top -c, il y a toujours 2 processus php.bin en cours d'exécution, qui frappent MySql en permanence et lui font utiliser environ 50% - 70% de CPU tout le temps. Voici un aperçu de ce à quoi il ressemble normalement.

 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

J'ai également changé les crons pour qu'ils s'exécutent toutes les 5 minutes, au lieu de la valeur par défaut toutes les minutes, mais le comportement reste le même.

Mon dernier changement était d'alterner toutes les 7 minutes et 8 minutes avec le 2 cron: exécuter des travaux commençant à 3 et 4 minutes d'intervalle, et avec ce seul 1 cron s'exécute à la fois avec 30% à 40% de CPU de MySQL.

Mon site n'a également aucun trafic en ce moment car je ne l'ai pas encore lancé. Ce comportement est-il normal depuis Magento car il n'y a rien avec le site? Je l'ai laissé reposer pendant 12 heures sans rien faire du tout et quand je regarde en haut, le cron fonctionne toujours et martèle MySQL.

MISE À JOUR: Il est maintenant clair que le problème n'est que le premier cron: exécutez le processus qui pose problème. J'ai changé les 2e et 3e éléments à chaque minute et laissé le premier à 8 minutes et il n'y a qu'un seul processus cron: run à la fois. D'après le commentaire ci-dessous, cela pourrait être un problème avec les installations de Bitnami Magento, mais c'est ma première expérience avec Magento, donc je ne sais pas si c'est un comportement attendu (j'espère vraiment que ce n'est pas le cas).

Fournir au moins une solution temporaire au problème, pour éviter de marteler votre serveur MySQL. Problème Git décrivant le problème

Au moins une partie du problème se résume à la table cron_schedule. Je recommanderais de faire un select count(*) from cron_schedule;et si cela renvoie plus de quelques centaines, alors vous avez le problème. Pour moi, cette requête a retourné 208 046 sur un serveur qui ne fonctionne que depuis quelques semaines.

Si vous rencontrez le problème, exécutez cette requête pour supprimer tout ce qui se trouve dans cette table, à l'exception des lignes récentes delete from cron_schedule where scheduled_at < date_sub(now(), interval 1 hour);

Ensuite, exécutez à nouveau la requête de comptage et elle devrait être plus basse. Le mien est passé de 208k à 252.

Après avoir exécuté cette requête, je remets les 3 crons standard à la norme une fois par minute, et comme par magie, ils fonctionnent tous les 3 presque instantanément. Retour à la normale pour autant que je sache.

Dans le problème github, un autre utilisateur suggère d'ajouter cette requête à crontab pour empêcher la table de croître à nouveau.

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

La dernière réponse de l'équipe Magento sur le problème était en septembre disant qu'ils ne pouvaient pas reproduire le problème, mais un certain nombre d'utilisateurs ont dit qu'ils vivaient la même chose, y compris moi-même. J'espère donc qu'ils corrigent ce problème afin que ce hack puisse être supprimé.

EDIT: Pour utiliser cette commande sur la crontab, vous devrez transmettre vos informations d'identification à MySQL d'une manière ou d'une autre. Voir mon commentaire ci-dessous si vous êtes sur une machine virtuelle ou un serveur dédié et que vous souhaitez mettre votre utilisateur / passer sur crontab, sinon vous devrez configurer un fichier d'informations d'identification MySQL. Et vous pouvez utiliser which mysqlpour trouver le chemin vers votre répertoire binaire mysql.