Настройка Cron-расписания
У меня есть следующие вопросы.
1) Magento предоставляет cron.php, shell/log.php & shell/indexer.php
И я настроил их следующим образом.Это всего лишь примеры. Они могут быть изменены для правильного вывода/функционирования/планирования.
*/60 * * * * sudo /opt/lampp/bin/php /opt/lampp/htdocs/magento/shell/log.php clean >> /opt/lampp/htdocs/magento/var/log/cronlog.txt
*/60 * * * * sudo /opt/lampp/bin/php /opt/lampp/htdocs/magento/shell/indexer.php reindexall >> /opt/lampp/htdocs/magento/var/log/cronindexer.txt
*/60 * * * * sudo /opt/lampp/bin/php /opt/lampp/htdocs/magento/cron.php clean >> /opt/lampp/htdocs/magento/var/log/croncron.txt
Это правильная настройка или только настройка cron.php выполняет все необходимые действия, а именно удаление журналов, выполнение индексации, очистку кэша и т.д.
2) Magento также предоставляет настройки cron в серверной части (система -> конфигурация -> система - > Cron (Запланированные задачи) - все время в минутах), где мы вводим частоту для задач. Установив эту опцию снова, нам нужно перейти к варианту 1, описанному выше. Итак, какова цель указания частоты/времени в обоих случаях (настройки crontab и серверной части) и какие времена/частоты будут приняты во внимание.
Я этого явно не понимаю. Кто-нибудь может пролить немного света?
1 answers
Выход
Вы перенаправляете вывод в файлы журналов - это нормально, - но эти журналы могут со временем раздуться или наполниться предупреждениями и ошибками, которые вы не собираетесь просматривать. Как минимум, настройте эти файлы со стандартным расширением .log в /var/log/ и настройте задание logrotate, чтобы сжать их через некоторое время.
Однако я вообще не перенаправляю вывод. Причина в том, что любой вывод во время задания cron будет записан в файл /var/log/cron. В кроме того, crontab можно настроить для каждого пользователя для отправки выходных данных по электронной почте. Есть некоторые модули Magento, которые возвращают свою собственную модель во время процесса cron, и, таким образом, Magento регистрирует имя модели, сохраняя его в таблице базы данных журнала cron. Это нежелательный для меня и бесполезный выход.
Вы можете получить визуальный обзор журналов, запущенных с помощью фантастического плагина от сотрудников Aoe и @fbrnc - Aoe_Scheduler. Его местоположение находится здесь, на Github: https://github.com/fbrnc/Aoe_Scheduler
Судоер
Не должно быть причин выполнять PHP как sudoer, так как рассматриваемые PHP-скрипты будут только обращаться и касаться БД. Им должен быть нужен только доступ для чтения.
Indexer.php
Переиндексация каждый час также не нужна. Я бы запланировал запуск индексатора на ночь, возможно, или в нерабочее время.
Cron.php
Очистка журналов cron - это что-то, что я делал бы каждые 30-60 дней , а не ежечасно. Вам все равно нужно будет настроить задание, которое не явно очищает cron, а скорее вызывает cron.php сам по себе. Это должно быть настроено на запуск каждые 5-10 минут. Magento планирует задания на 15 минут вперед, но запускает их только так часто, как работает ваш cron. Лично я настраиваю cron.php бегать каждые 5 минут.
Существуют некоторые споры о том, запускать ли cron как PHP-процесс или оболочку скрипт. Насколько я понимаю, если вы запустите его как PHP, он не будет блокировать выполнение следующего запроса планировщика, если предыдущий экземпляр все еще выполняется с последнего выполнения cron, что может быть желательно. Если вы используете скрипт bash, он будет заблокирован. Как вы хотите, чтобы это работало, зависит от вас, если вы предпочитаете, чтобы задания не выполнялись одновременно.
Log.php
Это хороший вариант для запуска по ночам до или после завершения работы вашего индексатора . Если у вас большая база данных, я рекомендуется сделать это с интервалом в 2-3 часа, поскольку для завершения индексирования может потребоваться несколько часов, особенно если у вас включен неструктурированный каталог.
Если вы никогда не запускали это или запускали его довольно редко, вы можете захотеть запустить log.php clean самостоятельно в первый раз без других запланированных заданий, и вы можете включить сообщение об обслуживании в своем магазине. Причина в том, что, по моему опыту, любая блокировка таблиц журналов вызывает значительные видимые проблемы у клиентов в вашем магазин.
Поскольку таблицы журналов хранятся в БД, записи выстраиваются в очередь за вашими удалениями, и, что ж, это может быть апокалиптическим (у меня был клиент со 100-миллиметровыми записями в таблице журналов посетителей - нам просто нужно было архивировать в автономном режиме, обрезать и начать заново; ни одно задание на удаление не будет выполнено во время окна обслуживания).
Я надеюсь, что это поможет. Желаю удачи.