Кеш Magento 2.2.x отключается автоматически

16

Во-первых, я не смог найти никакой информации об этом типе проблем в Интернете.

У нас есть производственная среда с интеграцией git . Мы вносим наши изменения только через git ( git pull ).

Проблема в том, что как-то на одном из шагов Magento кеширование отключается автоматически (все нули при проверке cache: status) . Это вызывает проблему, если это пропускается через программиста, что приводит к перегрузке сервера из-за большого «пробоя» трафика в Magento без кеша.

Может быть, некоторые из вас видели эту проблему раньше? Мы не знаем, когда и как это точно произойдет.
И это вроде случайно.

Обычные шаги мы делаем:

  • включение обслуживания
  • мерзавец
  • установка композитора (при необходимости)
  • модуль включения Vendor_ModuleName (при необходимости)
  • настройка: обновить (при необходимости)
  • очистка статического материала
  • команда развертывания
  • очистка кешей
  • очистка opcache
  • отключение обслуживания

Буду признателен за любые ценные предложения, которые могут помочь решить этот вид проблемы.

Macas
источник
Если вы сделаете setup:upgradeто кэш будет отключить automaticallyu
Amit Бера
@AmitBera Я должен не согласиться с тобой, даже если я перебью этого комманта, он не выключит кеш
Macas
Ладно. Я буду делать тесты .... см. Проверить скренерио
Амит Бера

Ответы:

16

Это похоже на известную проблему :
это происходит время от времени в проекте, над которым я работаю, но я не смог найти шаги для воспроизведения. Все, что я могу сказать, это то, что это происходит во время процесса развертывания.
Все, что я мог найти, это то, что при определенных обстоятельствах файл .regenerateзаписывается в varпапку (либо при обновлении установки, либо при установке / обновлении композитора), и если этот файл присутствует при запуске setup:di:compileкэша, он отключается и повторно включается, когда процесс компиляции завершается.
Почему-то иногда кеш не включается заново.
Мы взяли быстрый и грязный подход и сделали последний шаг процесса развертывания, php bin/magento cache:enableчтобы быть уверенными. ТАК в основном мы спрятали грязь под ковриком.

Вы можете найти код, который отключает кеш, здесь.
Он заключен в TODO: removeоператор.

Мариус
источник
1
могу подтвердить. скрывая это под ковриком, когда это происходит
Филипп Сандер
Хорошо, похоже, я не единственный с этим. Обычно мы получаем это, когда происходит ошибка и происходит сбой процесса развертывания. Глядя на вашу информацию, это будет иметь место. Спасибо за информацию, отметив это как ответ.
Macas
Кто-нибудь получил решение?
Маниш Госвами
5

Для тех, кто заинтересован, я думаю, что я могу пролить свет на эту проблему. Кажется, это проблема параллелизма (состояния гонки) в \ Magento \ Framework \ Code \ GeneratedFiles :: cleanGeneratedFiles, когда установлен флаг var / .regenerate и более одного процесса / запроса пытается очистить сгенерированные файлы .

Это более вероятно, когда у вас включен cron, и многие группы cron используют конфигурацию use_separate_process. Когда более одного процесса пытаются очистить одно и то же, FileIterator завершается ошибкой с различными сообщениями, похожими на:FilesystemIterator::__construct(/Users/adrianmartinez/Sites/r2-project-develop-b2b/environments/2-2-develop-b2b/magento/generated/code): failed to open dir: No such file or directory.

Перемещение вызова вверх $this->write->delete(self::REGENERATE_FLAG);, сразу после проверки наличия флага, решает проблему, так как первый поступающий процесс помечает себя как ответственного за очистку файлов.

Я оставляю здесь демонстрационное видео о том, как повторить проблему : https://youtu.be/9-X1cIIY7y8

И сценарий, используемый для этого:

#!/bin/bash

# \Magento\Framework\Code\GeneratedFiles has a concurrency problem
# Create regenerate flag and launch parallel commands that try to regenerate at the same time
# This is a real case, cron:run launches stand alone processes in parallel

# Created by magento composer installer upon code install or module enable/disable
touch var/.regenerate

# Launch parallel commands
# Error differs each execution, sometimes it even works
bin/magento cron:run --group=ddg_automation --bootstrap=standaloneProcessStarted=1 2>&1 &
bin/magento cron:run --group=index --bootstrap=standaloneProcessStarted=1 2>&1 &

wait
echo "All done"
Адриан Мартинес Гуантес
источник
Вы нашли решение?
Маниш Госвами
Я нашел, как воспроизвести эту проблему, но не нашел решение. github.com/magento/magento2/issues/17634
Маниш Госвами