标准cron中的2个是否应该一直运行？

我的问题归结为，是否应该始终运行多个magento cron：run -vvv进程并不断击中MySql。

我正在通过Google Cloud 设置Magento 2.2.1，并且具有3个标准的cron作业，这些作业是通过Google的1单击安装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

从顶部看-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分钟运行一次，而不是每分钟默认运行一次，但是行为保持不变。

我的最新更改是每7分钟和8分钟交替运行2个cron：run作业，分别从3分钟和4分钟开始，并且一次仅运行1个cron作业，而MySQL的CPU占30％-40％。

我的网站目前也没有流量，因为我还没有启动它。Magento的这种行为是否正常，因为该网站没有任何反应？我让它坐了12个小时，什么也没做，当我看到顶部时，cron仍在运行并重击MySQL。

更新：现在很清楚，问题只是引起问题的第一个cron：run进程。我将第二项和第三项改回了每分钟，而第一项则保留了8分钟，一次只运行了一个cron：run进程。从下面的评论可能是Bitnami Magento安装的问题，但这是我第一次使用Magento，因此我不知道这是否是预期的行为（我希望不是）。

— 较小的代码
source

我在安装Bitnami时遇到了类似的问题。到目前为止，我还无法弄清原因，但是当我在GCE仪表板中查看CPU利用率时，可以看到它大约在30天前开始在一定比例的CPU上启动。现在，我将其最大化，并添加了4个RAM和4个vCPU数量，以使服务器保持活动状态。我使用而不是top htop。有了它，我看到，我有十几行用magento cron:run -vvv。有些已经直播了几分钟。我将尝试找出为什么cron无法按预期运行。

— user5198077

当我将cron设置为每1分钟设置默认值时，我会得到相同的行为。正如我在问题中所述，我将其更改为每7和8分钟运行一次，它仅产生1个进程，但看起来好像做得太多了。听起来可能是个bitnami magento问题。

— codesmaller

是的，每隔7分钟更改一次会使我的服务器满意。从300％以上的cpu利用率和8 GB的RAM降低到40％（对于MySQL付费版）和1.7 GB的RAM。将研究如何打开Cron的完整日志记录。

— user5198077

而且-vvv是最大的详细日志记录，因此可以从crontab中删除arg。

— codesmaller

我看了磁盘操作（I / O）图表。当服务器似乎在“工作”时，读操作接近于零，而写操作则相当高。服务器停机（或停止响应）时，发生的事情是读取操作传递了写入操作。将我不太健康的2.2.0 Magento Bitnami安装与另一个BItnami（我认为仍在2.1.6或2.1.8上）进行比较，读/写处于非常低的水平，小于2，而对于不是很正常的情况健康（但现在可以正常工作）的读取值低于2，但写入数据通常超过1000！：O

— user5198077 '11

至少临时解决此问题，以避免重击MySQL服务器。Git问题描述问题

至少部分问题归结于cron_schedule表。我建议您执行一次select count(*) from cron_schedule;，如果返回的结果超过数百，那么您就遇到了问题。对我而言，该查询在仅运行了几周的服务器上返回了208,046。

如果您有问题，请运行此查询以删除该表中的所有内容（最近的行除外） delete from cron_schedule where scheduled_at < date_sub(now(), interval 1 hour);

然后再次运行计数查询，它应该低一点。我的数量从208k上升到252。

运行该查询后，我将所有3个标准crons每分钟设置回标准一次，就像魔术一样，它们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二进制目录的路径。

— 较小的代码
source

您的答案对我mysql magento-db -e "query"有用，但是在crontab中加上，其中magento-db是数据库名称（在我的情况下是bitnami_magento），当数据库有密码时它也可以使用吗？我通常会像输入数据库mysql -u somename -p，然后在提示符下输入密码。

— user5198077

使用您喜欢的搜索引擎，很容易找到相应的解决方案。在我给出免责声明之后，我将该部分留给用户/传递信息，但我将其发布：不要在共享主机上执行此操作，因为其他人可以通过top -c看到它。在这种情况下，请查找如何使用MySQL凭证文件，.mycnf或类似名称。这就是我所拥有的

*/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)";

— 较小的代码，2017年