2つの標準cronを常に実行する必要がありますか？

私の質問は、複数のmagento cron：run -vvvプロセスが常に実行されていて、MySqlを絶えずヒットしている場合に起こります。

私はGoogle Cloudを介してMagento 2.2.1をセットアップしています。Googleの1クリックのMagentoのインストールを介して事前セットアップされた3つの標準cronジョブがあります。

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

top -cを見ると、常に2つのphp.binプロセスが実行されています。これらのプロセスは常にMySqlにヒットし、常に約50％から70％のCPUを使用しています。以下は、通常の状態のスナップショットです。

 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

また、デフォルトの毎分ではなく、5分ごとに実行するようにcronを変更しましたが、動作は同じです。

私の最新の変更は、7分ごとと8分ごとに交互に行われ、2つのcron：runジョブが3分と4分間隔で開始し、MySQLから30％〜40％のCPUで一度に1つのcronジョブのみが実行されていました。

私のサイトはまだ立ち上げていないため、現在トラフィックもありません。サイトで何も起こっていないので、Magentoからのこの動作は正常ですか？私は何もせずに12時間そのままにしておきました。上を見ると、cronはまだ実行中でMySQLを攻撃しています。

更新：問題は、問題の原因となっている最初のcron：runプロセスにすぎないことが明らかになりました。2番目と3番目の項目を毎分に戻し、最初の項目を8分のままにして、一度に実行されているcron：runプロセスは1つだけです。以下のコメントから、それはBitnami Magentoのインストールに関する問題である可能性がありますが、これはMagentoでの最初の経験なので、これが予想される動作であるかどうかはわかりません（実際にはそうではないと思います）。

MySQLサーバーへの攻撃を避けるために、少なくとも一時的な問題の回避策を提供します。問題を説明するGitの問題

問題の少なくとも一部はcron_scheduleテーブルに起因します。私はを実行することselect count(*) from cron_schedule;をお勧めします。それが数百を超える場合は、問題があります。私にとって、このクエリは、数週間しか実行されていないサーバーで208,046を返しました。

問題がある場合は、このクエリを実行して、最近の行を除いて、テーブル内のすべてを削除します delete from cron_schedule where scheduled_at < date_sub(now(), interval 1 hour);

次に、countクエリを再度実行すると、それよりも低くなるはずです。鉱山は208kから252になりました。

そのクエリを実行した後、3つすべての標準cronを1分に1回標準に戻しました。魔法のように、3つすべてがほぼ瞬時に実行されます。私が知る限り、通常に戻ります。

githubの問題では、別のユーザーがそのクエリをcrontabに追加して、テーブルが再び大きくならないようにすることを提案しています。

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

この問題に関するMagentoチームからの最後の回答は、9月に問題を再現できないというものでしたが、私を含め、多くのユーザーが同じことを経験しているとフォローアップしています。うまくいけば、彼らはこのハックを削除できるようにこれを修正します。

編集：crontabでそのコマンドを使用するには、なんらかの方法でMySQLに資格情報を渡す必要があります。専用のVMまたはサーバーを使用していて、ユーザー/パスをcrontabに入れたい場合は、以下の私のコメントを参照してください。そうでない場合は、MySQL資格情報ファイルを設定する必要があります。また、を使用which mysqlして、mysqlバイナリディレクトリへのパスを見つけることができます。