Во-первых, я не смог найти никакой информации об этом типе проблем в Интернете.
У нас есть производственная среда с интеграцией git . Мы вносим наши изменения только через git ( git pull ).
Проблема в том, что как-то на одном из шагов Magento кеширование отключается автоматически (все нули при проверке cache: status) . Это вызывает проблему, если это пропускается через программиста, что приводит к перегрузке сервера из-за большого «пробоя» трафика в Magento без кеша.
Может быть, некоторые из вас видели эту проблему раньше? Мы не знаем, когда и как это точно произойдет.
И это вроде случайно.
Обычные шаги мы делаем:
- включение обслуживания
- мерзавец
- установка композитора (при необходимости)
- модуль включения Vendor_ModuleName (при необходимости)
- настройка: обновить (при необходимости)
- очистка статического материала
- команда развертывания
- очистка кешей
- очистка opcache
- отключение обслуживания
Буду признателен за любые ценные предложения, которые могут помочь решить этот вид проблемы.
magento2
magento2.2
cache
Macas
источник
источник
setup:upgrade
то кэш будет отключить automaticallyuОтветы:
Это похоже на известную проблему :
это происходит время от времени в проекте, над которым я работаю, но я не смог найти шаги для воспроизведения. Все, что я могу сказать, это то, что это происходит во время процесса развертывания.
Все, что я мог найти, это то, что при определенных обстоятельствах файл
.regenerate
записывается вvar
папку (либо при обновлении установки, либо при установке / обновлении композитора), и если этот файл присутствует при запускеsetup:di:compile
кэша, он отключается и повторно включается, когда процесс компиляции завершается.Почему-то иногда кеш не включается заново.
Мы взяли быстрый и грязный подход и сделали последний шаг процесса развертывания,
php bin/magento cache:enable
чтобы быть уверенными. ТАК в основном мы спрятали грязь под ковриком.Вы можете найти код, который отключает кеш, здесь.
Он заключен в
TODO: remove
оператор.источник
Для тех, кто заинтересован, я думаю, что я могу пролить свет на эту проблему. Кажется, это проблема параллелизма (состояния гонки) в \ 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
И сценарий, используемый для этого:
источник