Должны ли всегда работать 2 стандартных cron?

Мой вопрос сводится к тому, должны ли несколько процессов magento cron: run -vvv всегда выполняться и постоянно попадать на MySql.

Я настраиваю Magento 2.2.1 через Google Cloud, и у меня есть 3 стандартных задания cron, которые были предварительно настроены через установку Magento в один клик 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

Если посмотреть на top -c, то всегда запущено 2 процесса php.bin, которые постоянно работают с MySql и заставляют его все время использовать около 50-70% ЦП. Вот снимок того, как это обычно выглядит.

 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: запускать задания с интервалом в 3 и 4 минуты, причем одновременно выполнялось только одно задание cron с 30% - 40% ЦП от MySQL.

Мой сайт также не имеет трафика сейчас, потому что я еще не запустил его. Это нормальное поведение от Magento, так как с сайтом ничего не происходит? Я оставил его на 12 часов, ничего не делая, и когда я смотрю сверху, cron все еще работает и забивает MySQL.

ОБНОВЛЕНИЕ: теперь ясно, что проблема заключается только в первом cron: запустить процесс, который вызывает проблемы. Я изменил 2-й и 3-й элементы обратно на каждую минуту и оставил первый на 8-й минуте, и за один раз запущен только один запущенный процесс cron: run. Из комментария ниже это может быть проблема с установками Bitnami Magento, но это мой первый опыт работы с Magento, поэтому я не знаю, является ли это ожидаемым поведением (я действительно надеюсь, что это не так).

— codesmaller
источник

У меня похожие проблемы с установкой Битнами. На данный момент я не могу понять, почему, но когда я смотрю на загрузку ЦП в панели управления GCE, я вижу, что он начался на нескольких процентах ЦП около 30 дней назад. Теперь я увеличил его и добавил 4 х ОЗУ и 4 х количество виртуальных ЦП, чтобы сервер работал. Вместо верха я использовал htop. С ней я вижу , что у меня есть больше , чем десять строк с magento cron:run -vvv. Некоторые были живы в течение нескольких минут. Я постараюсь выяснить, почему cron не работает так, как ожидалось.

— user5198077

Я получаю то же самое поведение, когда cron устанавливает значение по умолчанию каждую 1 минуту. Я изменил его на запуск каждые 7 и 8 минут, как я описал в своем вопросе, и он запускает только 1 процесс, но все равно кажется, что он делает слишком много. Звучит как проблема bitnami magento, возможно.

— код меньшего

Да, переход на каждые 7 минут делал мой сервер счастливым. Ушли от 300% + загрузка процессора и 8 ГБ ОЗУ до 40% (для одного из платных MySQL) и 1,7 ГБ ОЗУ. Исследую, как включить полную регистрацию Cron.

— user5198077

Также -vvv - максимальное подробное ведение журнала, поэтому arg можно удалить из crontab.

— код меньшего

Я посмотрел на диаграмму операций с диском (I / O). Когда сервер «работает», операции чтения близки к нулю, а записи довольно высоки. Что происходит, когда сервер отключается (или перестает отвечать), так это то, что операции чтения пропускают записи. Сравнивая мою не очень здоровую версию 2.2.0 Magento Bitnami с другой BItnami (я думаю, что все еще на 2.1.6 или 2.1.8), чтение / запись находятся на очень низких уровнях, менее 2, в то время как для не очень здоровые (но теперь работают) чтения меньше 2, но записи часто выходят за пределы 1000! : O

— user5198077

Обеспечение хотя бы временного обхода проблемы, чтобы не забивать ваш сервер 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 стандартных кроны обратно к стандартным раз в минуту, и, как по волшебству, они все 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 по этому вопросу был в сентябре, что они не могут воспроизвести проблему, но ряд пользователей подтвердили, что испытывают то же самое, в том числе и я. Так что, надеюсь, они исправят это, так что этот взлом может быть удален.

РЕДАКТИРОВАТЬ: Чтобы использовать эту команду в crontab вам нужно каким-то образом передать свои учетные данные в MySQL. См. Мой комментарий ниже, если вы находитесь на выделенной виртуальной машине или сервере и хотите поставить своего пользователя / пользователя на crontab, в противном случае вам потребуется настроить файл учетных данных MySQL. И вы можете использовать, which mysqlчтобы найти путь к вашей двоичной директории mysql.

— codesmaller
источник

Ваш ответ работал для меня, но добавление в crontab, mysql magento-db -e "query"где 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)";

— codemaller