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

8

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).

magento2 database cron magento-2.2.1 codesmaller
la source
J'ai des problèmes similaires, avec une installation Bitnami. Pour l'instant, je ne peux pas comprendre pourquoi, mais quand je regarde l'utilisation du processeur dans le tableau de bord de GCE, je peux voir qu'il a commencé sur quelques pourcentages du processeur il y a près de 30 jours. Maintenant, je suis au maximum et j'ai ajouté 4 x RAM et 4 x nombre de vCPU pour maintenir le serveur en vie. Au lieu de haut, j'ai utilisé htop. Avec ça, je vois que j'ai plus de dix lignes avec magento cron:run -vvv. Certains sont en direct depuis plusieurs minutes. Je vais essayer de savoir pourquoi le cron ne fonctionne pas comme prévu.
user5198077
J'obtiens le même comportement lorsque le cron a défini la valeur par défaut toutes les 1 minute. Je l'ai changé pour fonctionner toutes les 7 et 8 minutes comme je l'ai décrit dans ma question et il ne génère qu'un seul processus, mais il semble toujours que cela en fait beaucoup trop. Cela ressemble peut-être à un problème de bitnami magento.
codesmaller
Oui, passer à toutes les 7 minutes a rendu mon serveur heureux. Passé de 300% + utilisation du processeur et 8 Go de RAM à 40% (pour l'un de MySQL payé) et 1,7 Go de RAM. J'examinerai comment activer la journalisation complète de Cron.
user5198077
De plus, -vvv correspond à la journalisation détaillée pour que l'argument puisse être supprimé de crontab.
codesmaller
J'ai jeté un coup d'œil sur le graphique des opérations de disque (E / S). Lorsque le serveur semble "fonctionner", les opérations de lecture sont proches de zéro, tandis que les écritures sont assez élevées. Ce qui se passe lorsque le serveur tombe en panne (ou cesse de répondre), c'est que les opérations de lecture passent les écritures. En comparant mon installation 2.2.0 Magento Bitnami pas si saine avec un autre BItnami (je pense toujours sur le 2.1.6 ou 2.1.8), la lecture / écriture est à des niveaux très bas, moins de 2, tandis que pour le pas-si- en bonne santé (mais qui fonctionne maintenant) les lectures sont inférieures à 2 mais les écritures dépassent souvent 1000! : O
user5198077

Réponses:

6

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.

codesmaller
la source
Votre réponse a fonctionné pour moi, mais en ajoutant dans crontab, avec mysql magento-db -e "query", où magento-db est le nom de la base de données (dans mon cas, c'est bitnami_magento), cela fonctionne-t-il également quand il y a un mot de passe pour la base de données? J'entre généralement dans la base de données comme mysql -u somename -p, puis saisis le mot de passe dans une invite.
user5198077
En utilisant votre moteur de recherche préféré, il sera facile de trouver quelques solutions pour cela; J'ai laissé cette partie pour les informations utilisateur / pass, mais je la posterai après avoir donné l'avertissement: ne le faites pas sur l'hébergement partagé, car il sera visible par d'autres avec top -c, entre autres. Dans ce cas, cherchez comment utiliser un fichier d'informations d'identification MySQL, .mycnf ou quelque chose comme ça. C'est ce que j'ai*/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