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

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

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

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

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

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

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

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

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

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

#!/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"